PHP2Shell: what this week's PHP patch means for your website

On 21 October 2026, the PHP project shipped an emergency security release for two critical flaws, tracked as CVE-2026-109618 and CVE-2026-109619 and nicknamed “PHP2Shell” by the researchers who found them. Both score 9.2 out of 10 and allow remote code execution without a password, meaning an attacker who finds a vulnerable server doesn’t need to log in to take it over.

Why this one is different

Most security advisories affect one application. This one sits underneath nearly all of them. PHP runs the back end of most of the web, including WordPress, Laravel, Magento, Drupal and plenty of custom-built systems. Neither flaw lives in any of those applications — it lives in PHP itself.

That means the usual advice doesn’t apply here. Updating WordPress doesn’t close this hole. Updating your plugins doesn’t either. The only fix is updating PHP on the server underneath them, and that’s a step your application can’t take for you.

What the two flaws are

• CVE-2026-109618 is a memory-handling bug. When a request runs out of memory, PHP is supposed to shut it down cleanly. Under the right conditions, that cleanup step runs on memory that was never properly set up, and a crafted request can turn that into code execution.
• CVE-2026-109619 is a use-after-free bug. PHP keeps some state in memory between requests and is supposed to clear it. Certain errors can skip that step, so the next request ends up reading memory it no longer owns.

Early reports before the patch shipped rated these as high as 10.0. PHP’s own advisory puts both at 9.2 — still critical, but with a narrower set of conditions needed to exploit them than the early numbers suggested.

The fixed versions

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

Anything below those version numbers on a supported branch is exposed. Branches older than PHP 8.2 are past their official end of life, so the safer move there isn’t a patch — it’s planning the upgrade.

What to actually check

1. Find out what version your site runs, not just your terminal. php -v shows the command-line version, which can differ from what your web server actually serves. Check a phpinfo() page or ask your host directly.
2. If you’re on shared or managed hosting, you can’t patch this yourself. Ask your host one question: have they applied the 21 October PHP security release, and does your plan include it.
3. If you manage your own server, update PHP, then restart PHP-FPM or Apache. Workers that were already running keep the old code in memory until they’re restarted — the update alone isn’t enough.
4. Don’t trust the version number alone. Some distributions backport security fixes into a package that still shows an older version. Checking the package changelog (apt changelog php8.3-cli on Debian/Ubuntu, for example) confirms whether the fix is actually in, rather than just assuming from the version string.

The practical point

Large-scale exploitation wasn’t confirmed at the time the patch shipped, but proof-of-concept code for a flaw like this tends to turn into real scanning within days of going public. If you run anything on PHP — a company site, a shop, a client portal — the question worth answering today is simple: was it patched before someone came looking.

If you’re not sure, that’s the whole point of asking your host or your development team to check rather than guessing.