October 30, 20264 min read
PHP2Shell: A Defender's Playbook for CVE-2026-109618 and CVE-2026-109619
Two memory-safety bugs in the PHP interpreter put roughly 70% of the web in scope. What happened, why patching was the only real fix, and how to verify you're actually covered.
On 21 October 2026 the PHP project shipped emergency releases for two critical flaws in the interpreter itself: CVE-2026-109618 and CVE-2026-109619, collectively named PHP2Shell. Both are memory-safety bugs that can lead to unauthenticated remote code execution, and both are rated 9.2 (Critical) under CVSS 4.0.
PHP powers roughly 69% of websites whose server-side language is known (W3Techs), so the blast radius was closer to Heartbleed or Log4Shell than to a typical framework CVE. The difference this time: there was no plugin to disable and no configuration flag that made the problem go away.
What Was Actually Broken
PHP2Shell isn't a bug in WordPress, Drupal or Joomla. It's in the runtime underneath them, which is why all three were demonstrated as exploitable.
- CVE-2026-109618: code execution through memory corruption in an out-of-memory path.
- CVE-2026-109619: a use-after-free in the upload-progress feature, where stale request-owned state can be reused by a later request on the same worker.
Affected versions reach back to PHP 5.4 (2012). Part of the story is uncomfortable: one of the underlying issues had been noticed in a 2024 audit but never fixed, because nobody could show a working exploit. AI-assisted research by Calif (through OpenAI's "Patch the Planet" project) and by Wiz changed that in August 2026.
The Timeline That Matters
- August 2026: discovered independently by two research teams.
- 17 October: Amazon Threat Intelligence later traced an exploitation attempt back to this date, four days before disclosure.
- 20 October: details leaked early. PHP published an advance notice telling everyone to prepare.
- 21 October: fixed releases 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Source patches were also published for the end-of-life 7.4, 8.0 and 8.1 lines, without official binaries.
Several European governments, the Wikimedia Foundation and the Internet Archive took services offline until they could patch. That looked dramatic, but for anything that couldn't be updated within hours it was the right call. The NSA's advisory said the same.
The Playbook
1. Find every PHP, not just the obvious ones
The web server is the easy part. PHP also hides in:
- Hosting control panels (cPanel, Plesk)
- Vendor appliances and "black box" admin UIs
- Container base images that haven't been rebuilt in months
- Internal tools nobody thinks of as "a website"
- Some Windows applications that bundle their own PHP
Ask your SBOM and your asset inventory, not your memory. If you don't have either, this is the incident that justifies building them.
2. Patch to a fixed version, then verify the running process
php -v # CLI version: not always the one serving traffic
php-fpm -v # the FPM binary actually handling requestsCheck what the running workers report, not only the package manager. A long-lived FPM pool keeps the old code in memory until it restarts. In containers, updating the host does nothing. Rebuild the image from a patched base and redeploy.
3. If you can't patch today, reduce exposure, don't pretend
PHP's maintainers were clear: there's no complete mitigation, and updating is the only safe option. Interim steps buy time:
- Put the application behind a WAF that has vendor rules for PHP2Shell. Cloudflare and Sophos, among others, shipped them.
- Following later guidance from the PHP project, set
session.upload_progress.enabled = 0until the next regular release. It closes a related vector (CVE-2026-115560). - Take the site offline if it holds sensitive data and can't be patched. An hour of downtime costs less than a backdoor.
4. Assume someone got there first
Exploitation began before the patch. For anything internet-facing that was unpatched on or after 17 October:
- Look for new or modified
.phpfiles in web roots and upload directories. - Review PHP worker crashes and segfaults around the disclosure window.
- Check for unexpected child processes of
php-fpmor the web server. - Rotate any secrets that live in the environment of the PHP process.
The Bigger Lesson
PHP2Shell is a memory-safety bug class in a 30-year-old C codebase, found by AI-assisted research and maintained by a foundation with about a dozen staff. Expect more of these. The organizations that recovered fastest already had three things before October: an accurate inventory, a way to rebuild and redeploy every image in hours, and authority to take a service offline without a committee meeting.