On Monday, October 20, 2026, the secret got out early. Details of two critical PHP flaws leaked before the planned disclosure. The PHP team moved its security release up a day and shipped the fixes on Wednesday, October 21.
That rushed week has a name now: PHP2Shell. It is not a WordPress plugin bug. It is not a theme bug. It is a flaw in PHP itself, the runtime underneath all of those things.
If you run anything on PHP, this one is worth understanding properly, because the usual advice, update your app, does not fix it.
What PHP2Shell actually is
PHP2Shell is the name researchers gave to two flaws in PHP core:
- CVE-2026-109618, rated 9.2 out of 10 under CVSS v4.0
- CVE-2026-109619, also rated 9.2
Both can let an attacker who is not logged in run code on a vulnerable web server by sending a crafted HTTP request. No username. No password. No click from a victim.
A quick glossary, because the rest only makes sense with it:
- Runtime: the program that runs your code. Your app is the recipe. PHP is the kitchen. If the kitchen is broken, a perfect recipe does not help.
- Remote code execution (RCE): an attacker gets to run their own commands on your server, as the web server user.
- Worker: a long lived PHP process that handles one request after another. PHP-FPM and Apache mod_php both use workers.
Both flaws live in how PHP sets up and cleans up after a web request. That is why they are so wide reaching. The vulnerable code runs before your application code gets a chance to defend itself.
Flaw one: the half written form
CVE-2026-109618 happens when PHP runs out of memory in the middle of setting up request data.
Think of it like a clerk filling in a form. Halfway through, the clerk runs out of paper and stops. Later, someone else picks up that half finished form and treats it as complete. They follow instructions that were never meant to be real.
In PHP terms, out of memory handling interrupts the setup while internal request data is only partly built. During cleanup, PHP can then treat that invalid data as valid. That confusion in memory is what an attacker can steer toward running code.
This is the flaw Cisco Talos describes as out of memory handling interrupting PHP while internal request data is only partially initialized, with cleanup then treating invalid data as valid.
Flaw two: the stale sticky note
CVE-2026-109619 is a close cousin, and it is easier to picture.
Imagine a worker reuses a desk. The last person left a sticky note on it. The new worker is supposed to throw that note away and start fresh, but for a brief moment the old note is still there, and the new worker reads it as if it were their own instructions.
In PHP terms, request specific state survives after the memory behind it has been freed. A later request on the same worker can reach that stale state before normal setup resets it. Again, memory that should be dead gets treated as live, and an attacker can use that window.
Neither flaw needs a bug in your code. Your code can be clean, reviewed, and fully patched, and still sit on top of a broken runtime.
Why updating WordPress did not fix it
This is the part most people missed in the first wave of headlines.
PHP powers WordPress, Drupal, Joomla, Laravel apps, and a long list of vendor tools and control panels. When you update WordPress, you update the app. You do not update PHP. Those are two different layers, updated by different people, on different schedules.
CISA, the US cybersecurity agency, lists the affected setups plainly: Apache with mod_php, PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed. It calls Apache mod_php the highest risk, because the demonstrated exploit there triggers before any site code runs.
So the checklist question is not "is my CMS up to date?" It is "is my PHP up to date?" If you cannot answer the second question, you have not finished the job.
Why finding every PHP install is the hard part
Patching sounds simple: install the fixed version and move on. In practice, PHP hides.
It hides inside Docker images built months ago. It hides inside vendor software that never mentions PHP in its marketing. It hides on a shared hosting account you forgot about, and in an internal tool someone set up years ago and never documented.
CISA makes the same point in its alert: PHP is often a component of other software, and its presence may not be directly visible. That is why the first step is an inventory, not a patch. You cannot patch what you have not found.
A practical way to start:
- List your servers, containers, and hosting accounts.
- On each one, check the runtime itself, not the app. On a server,
php -vtells you the version of the command line PHP, which is a start, but check what your web server actually uses too. A system can have more than one PHP installed. - Check your container images and rebuild any that bundle an old PHP, even if the app inside them is current.
- Ask your hosting provider or platform what PHP version they run for you, if you do not control the server. Managed WordPress hosts patched many customers automatically. Unmanaged servers did not patch themselves.
What to do today
The fixed versions, for supported branches, are:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
Pick the fixed version for the branch you already run. Do not jump branches in a panic unless you have tested it. A branch jump can break an app in ways a patch release should not.
Then do the step people skip: restart every PHP worker. Restart PHP-FPM, restart Apache if you use mod_php, restart queue workers. A running process keeps the old, vulnerable code in memory until it restarts. Installing the patch on disk is not enough while the old worker is still alive.
If you run PHP 8.1 or earlier, there is no official patch for your branch. Those versions are out of support. Your real options are to upgrade to a supported branch, or, as CISA puts it, take the PHP based system offline until it can be patched or updated. That sounds drastic. It is the honest version of "we have no fix for this version."
A web application firewall may block some attack attempts, and it is worth turning on if you have one. But it is not a complete fix. The PHP team and CISA are clear on this: patching is the only complete fix. A firewall rule can miss a variant. A patched runtime cannot be exploited through these two flaws at all.
Finally, watch for the signs of a worker gone wrong: a PHP worker process launching a shell, a scripting interpreter, or a download tool. That is not normal web server behaviour. If you see it, treat it as an incident, not a curiosity.
What about the AI angle?
You will have seen the other headline: these flaws were found with help from frontier AI models. Researchers at Calif and Wiz have said AI tools helped them trace and verify a complex chain that human researchers might have dismissed as impractical.
That part matters, but not for the reason the hype suggests. It does not mean AI is now finding every bug overnight. It means the cost of finding a hard, decade old bug just dropped. A flaw that sat in PHP since the 5.4 era, according to the researchers, stayed hidden for years partly because exploiting it looked too complex to bother with. Once that complexity barrier falls, the patching window matters more than ever.
The lesson is boring and useful: your patch process is now part of your security posture, not an admin chore you get to later. The gap between "patch available" and "patch installed everywhere, workers restarted" is the gap attackers live in.
Reports of early attack attempts circulated before and just after the patch, including from Cloudflare. But nuance matters here: CISA said that as of its alert, it had not observed successful exploitation in the wild. Early attempts are not the same as confirmed break ins. Do not let either extreme mislead you. The flaws are real and critical, the patch exists, and unpatched servers are the ones at risk.
The takeaway
Most security advice tells you to patch your app. PHP2Shell is a reminder to patch the layer underneath your app too.
Check your PHP version. Check it in every place PHP could be hiding, not just the one server you remember. Upgrade to a fixed release. Restart the workers. And if you are on an unsupported version, make the upgrade plan this week, not someday.
Your app was never the only thing an attacker could reach. This week proved it.
What did you find when you checked? Did PHP turn up somewhere you did not expect?
Sources
- CISA alert: Critical Vulnerabilities in PHP Require Immediate Patching: https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching
- Cisco Talos: Two critical RCEs in PHP core: https://blog.talosintelligence.com/two-critical-rces-in-php-core/
- Tenable FAQ on CVE-2026-109618 and CVE-2026-109619: https://www.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote
- DigitalOcean: Critical PHP RCE Vulnerabilities, patch now: https://www.digitalocean.com/blog/critical-php-rce-vulnerabilities-patch-now
Top comments (0)