Exploited Before the Patch: What php2shell Says About the Patch Window
Attackers probed the bug before the fix existed. The time between disclosure and exploitation is no longer something defenders can plan around.
The timeline
On October 21, 2026, the PHP project released fixes for two vulnerabilities now known as php2shell: CVE-2026-109618 and CVE-2026-109619. Together they allow unauthenticated remote code execution against PHP installations serving web requests. The PHP security team rated each one 9.2 (critical) under CVSS v4.0.
Status as of October 23, 2026: Neither CVE is in CISA’s Known Exploited Vulnerabilities catalog yet, and CISA had not observed exploitation when it published its alert. Honeypot operators including Amazon and watchTowr have reported exploitation attempts. Treat this as actively targeted.
The order of events is the story:
- October 17 — Amazon’s MadPot honeypot network recorded an exploitation attempt. That was four days before public disclosure. Amazon says it is unclear how the attacker obtained exploit information.
- October 20 — The CVE identifiers circulated publicly. PHP had published an advance notice of a release, and moved that release up by a day after the leak.
- October 21 — Patches and advisories shipped. The same day, Amazon saw more exploitation attempts, with payloads suggesting multiple actors. Cloudflare deployed WAF rules. CISA issued an alert telling organizations to patch immediately.
For most teams, “patch window” means the time between a fix being available and an attacker using the bug. For php2shell, that window was negative.
What actually broke
These are bugs in the PHP runtime, not in a framework or plugin. That is what makes them unusual.
CVE-2026-109618 is a memory corruption issue. If PHP runs out of memory while its internal request data is only partly initialized, the cleanup that follows treats the incomplete data as valid.
CVE-2026-109619 is a use-after-free. State left behind by one request can point to memory that has already been freed, and a later request handled by the same worker can use it. PHP also lists memory disclosure as a confirmed impact.
Both can be reached by an unauthenticated web request. Because the bugs live in the runtime, your application code does not have to contain a flaw for the server to be exposed. The vulnerable code path goes back to PHP 5.4.
Who is exposed
According to the PHP project, any installation serving web requests is at risk. That includes PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed.
mod_php is the highest-risk configuration. A demonstrated exploit runs before any application code executes, so your application’s own input validation, authentication, and WAF-aware routing never get a chance to help.
The researchers who built the exploit chain report confirmed pre-authentication RCE against specific versions of WordPress, Drupal, Joomla, and Magento. If you run any of them, you are in scope.
The fixed releases are:
| Branch | Fixed version |
|---|---|
| 8.5 | 8.5.12 |
| 8.4 | 8.4.27 |
| 8.3 | 8.3.36 |
| 8.2 | 8.2.35 |
PHP 7.4 through 8.1 have only source-level backports. PHP 5.4 through 7.3 are end-of-life and will not receive a fix.
The hard part is finding your PHP
Patching a server you know about takes minutes. The real risk sits in the PHP you have forgotten:
- A marketing WordPress site set up by an agency three years ago.
- A vendor appliance or admin panel that bundles its own PHP.
- A legacy internal tool running in a container image nobody has rebuilt.
- A staging environment exposed to the internet “temporarily.”
CISA’s first recommended action is not “patch.” It is inventory every system running PHP, including PHP bundled inside other software. That is the step most teams cannot complete quickly, and it is the step that decides whether the patch actually reaches every exposed system.
A first pass does not need a tool. On each host, look for PHP binaries and the Apache module, including copies bundled outside the package manager:
# PHP CLI, FPM and CGI binaries anywhere on the filesystem
find / -xdev -type f \( -name 'php' -o -name 'php[0-9]*' -o -name 'php-fpm*' -o -name 'php-cgi*' \) 2>/dev/null
# mod_php, the highest-risk configuration
find / -xdev -name 'libphp*.so' 2>/dev/nullRun each binary you find with -v to get its version. For container images, check every image you ship, not just the ones running right now:
docker run --rm --entrypoint php <image> -vOn the supported branches, anything older than 8.2.35, 8.3.36, 8.4.27, or 8.5.12 is vulnerable. Anything on 8.1 or earlier has no official fixed release and should be isolated.
What to do this week
- Inventory. Find every host, container image, and appliance running PHP. Check base images, not just running hosts. Include third-party products that embed PHP.
- Patch internet-facing systems first. Upgrade to 8.5.12, 8.4.27, 8.3.36, or 8.2.35. Linux distributions received the fixes in advance, so check your distribution’s security tracker for updated packages.
- Isolate what you cannot patch. PHP 8.1 and earlier should come off the internet. CISA recommends taking systems offline if they cannot be updated.
- Use a WAF as a stopgap, not a fix. Vendor rules buy time. They do not remove the bug, and with mod_php the exploit fires early in request handling.
- Watch for the post-exploitation pattern. PHP worker processes should not launch shells or download tools. Alert on it.
- Do not run unverified PoCs. Code claiming to exploit php2shell is circulating. The PHP security team found no functional public exploits at release, and unverified exploit code may itself be malware. Test in an isolated environment, if at all.
The AI angle
The PHP Foundation credited Calif, OpenAI, Wiz, and others for the research and disclosure. Calif and Wiz have both said they used AI models in their work.
We do not know which steps were AI-assisted. But the direction is clear, and it matches what we wrote in Your Next Security Tester Is an AI Agent: AI is making it cheaper to find and validate deep bugs in mature, heavily reviewed code. A memory corruption bug in a language runtime, present since PHP 5.4, is exactly the kind of finding that used to take rare expertise and a lot of time.
That capability is not exclusive to defenders. When discovery gets faster, so does everything downstream: leaks, rediscovery, exploit development, and mass scanning. The four days between the first observed attempt and the patch are a preview, not an outlier.
The practical consequence is that “we patch within 30 days” is no longer a security posture. It is an assumption that the attacker is slower than your change-management process.
Speed is a property of your system, not your team
The teams that patched php2shell on October 21 did not work harder than everyone else. They already knew:
- Where every PHP runtime lives, including the bundled ones.
- Which of those systems are internet-facing.
- Who owns each one, and how to ship a change to it today.
- Which systems are end-of-life and need isolation instead of a patch.
That knowledge has to exist before the advisory arrives. When the window between disclosure and exploitation shrinks to zero, your response time is set by your inventory, not by your incident process.
Rta Labs helps engineering teams find what they are running, understand where it is exposed, and validate fixes with evidence. If php2shell exposed gaps in your inventory or patch process, get in touch.
Links: CISA alert · Tenable php2shell FAQ · Rapid7 analysis · Google Cloud guidance