php2shell: two critical PHP flaws and what to do about them

What happened

On October 21, 2026 the PHP project fixed two memory bugs in PHP itself. Not a plugin, not a framework. The runtime. They are tracked as CVE-2026-109618 and CVE-2026-109619, nicknamed php2shell. Each scores 9.2 Critical.

The first bug fires when a request pushes PHP over its memory limit at the wrong moment during startup. The second lets one request reuse memory left behind by a previous request on the same worker. Either way the attacker ends up running code on your server.

The dangerous part is timing. On Apache with mod_php, the bug triggers before your application loads. Login pages, CSRF tokens, and framework middleware never get a say. PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed are also affected.

Why it spread so fast

The release was supposed to be coordinated. It leaked early. CVE numbers circulated a day ahead, a proof-of-concept video was posted by mistake, and patched builds appeared publicly hours before the official release. PHP pulled the announcement forward while distributions were still packaging.

Several teams found these bugs independently within weeks of each other, with help from AI tooling, and scanning for them started the day the fix landed. The old assumption that you have a week after a critical advisory is gone. For a bug that needs no login, assume hours.

Are you affected?

If PHP serves any traffic from the internet, assume yes until you check. That covers WordPress, WooCommerce, Drupal, Joomla, Magento, Laravel, phpMyAdmin, Nextcloud, and the admin panels and appliances that embed PHP quietly. On managed hosting, ask your host when they patched.

Fixed versions are **PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35**. PHP 8.1 and older are no longer maintained upstream, so your operating system vendor is the fix path. Major distributions shipped patches the same day, including for releases that are years old.

Two traps. Distributions backport fixes without changing the version number, so check the package revision, not `php -v`. And containers carry their own PHP. Patching the host does nothing for an image you built last month.

What to do now

**1. List every place PHP serves HTTP.** Hosts, containers, managed platforms, appliances. Note the version and who owns the update. The box you forget is the one that gets hit.

**2. Patch and restart.** Upgrade to the fixed release or your vendor's package, then restart Apache or PHP-FPM. Running workers keep the old code until they are replaced. Rebuild and redeploy any container that ships PHP.

**3. If you cannot patch today, narrow the attack.** Set `session.upload_progress.enabled=0`, and on PHP 8.5 set `fatal_error_backtraces=0`. Restart all workers. At your proxy or CDN, cap request body size so oversized POSTs never reach PHP. Do not use `RLIMIT_AS` as a shortcut; it can trigger the very failure the first bug needs. These settings reduce exposure. They do not close the bugs.

**4. Look for signs of attack.** A web worker spawning a shell is the clearest signal. In the PHP error log, `Allowed memory size ... exhausted` with `Unknown on line 0` means it happened before any script ran. Segfaults in web server child processes often mark failed attempts. A successful exploit can return 200 and leave the worker running, so do not wait for a crash.

**5. If you were hit, rotate everything the server could read.** Database credentials, API keys, secrets in config files. Audit admin users. Rebuild instead of cleaning.

Stop telling attackers what you run

Mass exploitation starts with a fingerprint. Attackers look for sites that announce PHP, then send the payload. An `X-Powered-By: PHP/8.1.2` header, a version string in the `Server` header, and a reachable `/xmlrpc.php` put you on the shortlist.

None of those help your users. Removing them is a one-line change at the web server and takes you off the cheap scanning lists. Our scanner flags X-Powered-By disclosure and Server version banners on every scan, and the WordPress check covers the usual exposed endpoints. This is not a substitute for patching. It is the difference between the first wave and the third.

The habits that make the next one boring

Every critical advisory triggers the same scramble: what do we run, is it affected, where is the fix, did it stick. Teams that handle it calmly answered the first two questions months ago.

**Keep one live inventory** of what you run on the public internet, with versions and owners. Pull it from the systems themselves where you can.

**Watch a few feeds.** Your distribution's security list, upstream advisories for your runtime and CMS, and one aggregator. Our CVE notices page tracks vendor fixes for common web stacks.

**Agree a patch window you can hit.** For no-login remote code execution, that is hours, which means someone has standing authority to patch production without a meeting. Write that exception down now.

**Build the restart into the deploy.** An upgrade is not done until every worker is replaced. Verify from the outside afterward.

**Let the evidence write itself.** Inventory, vulnerability management, patch timelines, and change control are all controls an auditor will ask about under SOC 2, ISO 27001, or PCI DSS. Scorifya Controls records them as you go, so the proof of what you patched and when exists before anyone asks.

Scope reminder

Scorifya does not run PHP, so our scanner, Watch, and Controls are not affected. External scans see what an attacker sees: headers, endpoints, certificates, DNS. They can tell you a site advertises PHP. They cannot see the installed package. Confirming the patch is a job for your package manager and a restart.