Two CVSS 9.2 flaws in the PHP Core (CVE-2026-109618/109619) enable unauthenticated RCE, with attacks detected four days before the patch - deep dive into the OOM and use-after-free mechanics, the leak timeline, the role of WAFs, and a four-part response plan for organizations.
Imagine an organization whose website is developed with discipline: SQL injection protection, HTTPS, a Web Application Firewall (WAF), and diligently updated plugins - yet a hacker can still take over the server without knowing a single password or finding a single flaw in the site itself.
That is the horror of PHP2Shell, the name for two critical vulnerabilities - CVE-2026-109618 and CVE-2026-109619 - each scoring 9.2 on the CVSS v4.0 scale. Unlike typical website flaws, these bugs live inside the PHP Core, the engine behind an enormous share of the world’s websites and web applications, whether built on WordPress, Laravel, Drupal, or custom in-house code.
What makes this event even more notable is not just the severity, but the fact that exploitation attempts were detected four days before the official patch announcement. PHP2Shell is therefore not just another vulnerability story - it shows the window between threat discovery and system defense is shrinking alarmingly.
The problem is not in the website - it is in the heart of PHP
When a website gets breached, we usually think of insecure code, mismanaged permissions, or outdated plugins. PHP2Shell is different: the flaws arise directly in how the PHP interpreter manages memory and internal state. Technically, the two vulnerabilities differ in an important way.
CVE-2026-109618: when memory runs out at the wrong moment. While PHP processes an HTTP request, an out-of-memory (OOM) condition at an inopportune point can leave some data structures partially built. If the error-handling and cleanup path then proceeds assuming those structures are valid, the result can be memory corruption - opening the door for an attacker to take control of execution.
CVE-2026-109619: stale memory state reused. The second flaw involves internal state still referencing memory from a previous request even after that memory was freed. When a new request is handled by the same worker, PHP may dereference invalid pointers - a use-after-free condition that can crash the process or run attacker-controlled code.
If exploited successfully, the worst-case outcome is Remote Code Execution (RCE) - running code on the server remotely, with no authentication required. The risk is especially high on Apache with mod_php, since some attack paths trigger before application code even starts; PHP-FPM has confirmed attack paths as well. In short: however safe your application code is, it cannot substitute for fixing the PHP Core underneath it.
Not just legacy PHP - current versions are affected too
Researchers found some of the problem paths have existed in PHP since version 5.4 - a reminder that mistakes in foundational components can hide for many years. The PHP Foundation shipped a security release on 21 October 2026 (see the official PHP announcement) fixing both vulnerabilities in:
| PHP branch | Patched version |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
For PHP 8.1 and older - no longer supported by the core project - organizations must check for patches from their OS vendor or extended-support provider. A version number alone may not be enough, since some vendors backport fixes into the same package version. The key question is not "which PHP version do we run?" but "has the PHP actually serving our site received the security fix?"
The early leak: when coordinated disclosure starts to crumble
One of the most interesting aspects of PHP2Shell is what happened before the official disclosure. The PHP team planned a coordinated vulnerability disclosure process, holding the vulnerability details under an embargo period so developers and distributors could prepare patches before the public announcement on 22 October 2026. Events unfolded differently.
17 October - attacks detected before disclosure. Amazon Threat Intelligence’s MadPot honeypot recorded PHP2Shell exploitation attempts a full four days before public disclosure, per the AWS report. Attackers used infrastructure that obscured its origin; AWS noted it does not yet know how the attackers obtained the vulnerability details, nor could it confirm that identical attacks would succeed against real systems.
20 October - the CVE identifiers surface online. Around 15:00 UTC, information about the vulnerabilities began spreading through the security community and social media. The PHP team decided to move the patch release up one day, from 22 to 21 October. Around 20:00 UTC, security research firm Calif unintentionally published a proof-of-concept demo video early (see Calif’s research); the video was later removed, but copies had already spread.
21 October - premature disclosure and a race against time. At 07:41 UTC, Chainguard released container images containing the fix ahead of the coordinated disclosure time - raising concern that attackers could diff the patched and unpatched software to find the attack. At 14:00 UTC, the PHP team officially released the security release.
The whole episode highlights a core problem of coordinated disclosure: even when every party agrees to hold the embargo, a partial breach can force the entire defensive plan to change overnight.
How fast did real attacks appear?
Once the news spread, threat-detection systems at multiple providers saw rapid increases in scanning and PHP2Shell exploitation attempts. AWS reported attack attempts from multiple sources before the patch shipped, while Fastly detected scanning tools with PHP2Shell-related names from the morning of 21 October. After the patches and technical details went public, additional attack tooling and PoCs appeared quickly.
One crucial distinction, however: detecting attack traffic does not equal confirmed server takeovers. Honeypot and WAF data mostly reflects scanning, payload testing, and exploitation attempts - not the full outcomes of intrusions. Still, the event makes clear that for critical vulnerabilities, organizations may no longer have days to decide.
How do Cloudflare and WAFs help against PHP2Shell?
When the flaw sits in the PHP Core, what can a front-line WAF do? It cannot fix the bug inside PHP, but it can detect and block HTTP requests matching known attack patterns before they reach the origin server - for PHP2Shell, defenses may look at anomalous request bodies, multipart form data structures, and data shapes likely to trigger the memory-handling bugs.
Cloudflare disclosed that it had built and deployed WAF rules for these vulnerabilities since early October, enabling protection before the public announcement - including for Free Plan users - and shipped additional detection-rule updates on 3 November 2026 for evolving attack patterns. Organizations using Cloudflare or AWS WAF should verify the relevant rule sets are enabled, review security events, and ensure no bypasses let hostile requests reach the origin directly.
But there is a limitation that must not be overlooked: a WAF is risk mitigation, not a replacement for the security patch. If attackers craft a payload that evades detection rules, or reach the origin by bypassing the WAF, an unpatched system remains exposed - which is why the PHP Security Team reaffirms that updating the software is the essential measure.
Another vulnerability admins should not overlook
After the PHP2Shell patch on 21 October, the PHP team announced additional details on 23 October about CVE-2026-115560, related to the session upload progress feature. Its preconditions are far more specific - involving applications that change session serialization settings while using the upload progress feature. PHP recommends considering temporarily disabling session.upload_progress.enabled on systems that do not need the feature until the next patch cycle. The lesson: even after applying the first round of updates, following further security advisories remains necessary.
How should organizations respond?
PHP2Shell is a wake-up call to revisit vulnerability management, especially for foundational components exposed to the internet. Four priorities:
- Audit PHP everywhere, not just production: inventory web servers, virtual machines, Docker containers, Kubernetes workloads, and easily missed systems such as UAT, staging, and internal systems reachable from outside. Check the version actually processing requests - not just the output of
php -v. - Patch and test compatibility: apply the security fix from PHP or a trusted vendor, and test the application afterward. For legacy systems that cannot upgrade immediately, plan isolation, restrict access, and add compensating controls while migrating to a supported version.
- Look for signs of prior intrusion: patching closes the hole but does not guarantee the system was never attacked before. Security teams should review PHP error logs, HTTP access logs, out-of-memory errors inconsistent with normal behavior, and suspicious shell or process activity under the web server account. If anything looks off, trigger incident response immediately.
- Rework emergency patching processes: organizations applying a uniform 7-day or 30-day patch cycle should carve out a separate policy for critical vulnerabilities with evidence of active exploitation. Public-facing, unauthenticated-exploitable systems deserve immediate triage - with a response target of hours, where risk and readiness allow. Speed matters, but so does verifying outcomes, rolling back safely, and confirming the system is actually protected.
Final lesson: security does not end at the code we write
PHP2Shell shows that even long-trusted foundational technology can harbor severe defects. Website security depends not only on developer skill but on the interpreter, runtime, operating system, container images, cloud infrastructure - the entire software supply chain.
It also exposed the fragility of coordinated disclosure, where leaks precede the schedule and attack tooling appears before every organization has a patch ready. The most important lesson for organizations may not be "which PHP version do we run?" but "if a critical vulnerability hits a core system tomorrow and attackers start exploiting it today, how fast can we detect, assess, defend, and patch?"
In today’s cybersecurity world, the ability to respond to threats quickly and accurately may be what separates organizations that weather the incident from those that suffer major damage.
Sources
- PHP Foundation thephp.foundation
- official PHP announcement www.php.net
- AWS report aws.amazon.com
- Calif’s research calif.io
- Cloudflare disclosed blog.cloudflare.com
