DEV Community

Cover image for php2shell: Two Critical PHP Core Bugs Leaked Before the Patch
Temuri Takalandze
Temuri Takalandze

Posted on Originally published at abgeo.dev

php2shell: Two Critical PHP Core Bugs Leaked Before the Patch

PHP ships an emergency security release today, October 21, 2026, at 14:00 UTC. The release fixes two critical bugs in
PHP core: CVE-2026-109618 and CVE-2026-109619. Each one has a CVSS v4.0 score of 9.2. People already call them
"php2shell".

The details leaked on Hacker News one day before the embargo ended. watchTowr confirmed that the bugs are real and
reproduced one of them in their lab. PHP then moved the release one day earlier. Many numbers are going around right
now, and some of them are wrong. The leaked post said CVSS 10.0. The official score is 9.2.

The bigger problem is who gets the fix. PHP supports only 8.2 and later. On Shodan, 59% of internet-facing hosts that
show a PHP version run 8.1 or older. Those servers will not get an official patch. Some Linux distributions backport
fixes, so check your distribution's security tracker before you panic.

If you run PHP, do two things today. Find every installation, including the ones inside containers and appliances.
Then plan the upgrade for anything older than 8.2. After the release, install the update and restart PHP-FPM.

The full post on my blog explains what is confirmed and what is still a rumor. It also has a short checklist and a
detection signal you can use right now.

Originally published on abgeo.dev.

Top comments (2)

Collapse
 
kholnnaw profile image
kholnnaw •

any insight on how these bugs interact with opcache, do we need a full restart or can a reload clear the compromised state?

Collapse
 
abgeo profile image
Temuri Takalandze •

Good question. Short answer: we don't know yet how these bugs interact with OPcache, because the root cause isn't public. But a few things hold regardless:

The fix is in the PHP binary, not your scripts. OPcache caches compiled scripts. It doesn't patch or cache the engine itself, so clearing OPcache does nothing for a core bug. What matters is that every running PHP process is the new binary.

Prefer a full restart over a reload. For PHP-FPM, a full systemctl restart php-fpm (or your distro's service name) guarantees new processes on the new binary and a fresh OPcache shared memory segment. For mod_php, restart Apache fully rather than using a graceful reload.

"Compromised state" is a different problem. If a server may have been exploited before you patched, a restart isn't remediation. An attacker with code execution can write files to the web root, add cron jobs, or tamper with the OPcache file cache, and all of that survives a restart.