Patch PHP today, not this week

Second security story in one week. On October 21 PHP shipped an emergency release for two critical bugs, CVE-2026-109618 and CVE-2026-109619, both rated 9.2. People are calling it PHP2Shell. The details leaked a day before the planned disclosure, so the patch went out early and the clock started for everyone at the same time, attackers included.

What it is, in plain words

Both bugs live in PHP itself, in how it sets up and cleans up memory for each web request. One leaves half-initialised data behind after an out-of-memory error. The other keeps request data around after it’s been freed, so the next request on the same worker can touch it. Either way the result is the same: an attacker can get code running on your server with a single request, without logging in, and in some setups before your application code even runs.

And it got more urgent since. Cloud providers are now emailing every customer: DigitalOcean’s notice says proof-of-concept exploit code is public, that every PHP version from PHP 5 onward is in scope, and that they’re pulling affected 1-Click Marketplace images (WordPress, LAMP, LEMP, Laravel) until they’re patched. When your hosting provider emails all customers about one bug, that tells you how serious it is.

It isn’t about one framework. PHP says every install that serves web traffic is at risk: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, LiteSpeed. Wiz showed it working against WordPress, Drupal and Joomla, plus a memory leak path that can expose passwords, tokens and API keys. That last part connects straight to last week’s lesson.

The fixed versions

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

PHP 8.1 and older are end of life, so there’s no official release for them. The PHP team published minimal source patches for 7.4, 8.0 and 8.1 and some Linux distributions will backport fixes, but if you’re there, this is the week to finally move to 8.2 or newer.

What I’d do today

1. Find every PHP install. Not just the main app. The old marketing site, the admin panel nobody logs into, the vendor tool that ships its own PHP, the WordPress blog a team set up three years ago. The one you forgot is the one that gets hit.

2. Patch the internet-facing ones first. Then everything else. On shared hosting, open your control panel and check the PHP version yourself. Don’t assume the host already did it. If you deployed a one-click image (WordPress, LAMP, Laravel) on a cloud server, that server is yours to patch, not the provider’s. And remember WordPress, Laravel and friends may need their own updates on top of PHP.

3. If you can’t upgrade right away, take end-of-life PHP off the public internet or put it behind a WAF. Huntress also suggests setting session.upload_progress.enabled = Off in php.ini as a stopgap for old versions. Treat that as buying a day, not a fix: with exploit code public, patching is the only real answer.

4. Watch for the signs. PHP worker processes starting shells or download tools, new files in the web root, new cron jobs, new admin accounts. If you see that, isolate the server and keep the logs.

The bigger point

PHP still runs a huge part of the web, and a lot of it isn’t owned by anyone who reads security advisories. The real question this week isn’t “are we patched?” It’s “who owns each of these servers, and would they know?” If the answer is a long silence, fix that too.

Sources

• Huntress: php2shell, leaked critical PHP vulnerabilities
• Qualys: PHP critical security release
• DigitalOcean customer security notice, October 22, 2026 (email to all customers)
• CISA alert, October 21, 2026