PHP2Shell, the name given to CVE-2026-109618 and CVE-2026-109619, became one of the week's most prominent cybersecurity stories following their disclosure on 21 October. Both vulnerabilities received CVSS scores of 9.2 and affect PHP's core memory handling rather than a particular application. PHP powers a large proportion of websites, including installations running WordPress, Drupal, Magento and Joomla, giving vulnerabilities in the interpreter a potentially broad reach. A week into the response, however, the picture is more nuanced than the initial severity ratings suggested. The flaws were serious, but turning them into reliable remote code execution proved more difficult than the first wave of headlines implied.

The vulnerabilities

Both vulnerabilities involve PHP's handling of memory exhaustion and internal state. One relevant mechanism is longjmp(), which allows execution to jump out of a function without following the normal return path. When PHP encounters an out-of-memory condition, this abrupt unwind can leave internal data structures in an inconsistent state if an operation has not completed safely.

The vulnerable path involved session.upload_progress, a feature enabled by default since 2012. It processes session state during request handling, before the application has begun executing its own code. A crafted multipart request can trigger the vulnerable behaviour without authentication or application-specific code, which helps explain the broad concern around the disclosure.

Reliable exploitation is more demanding than triggering the underlying error. An attacker must manipulate memory in a predictable way, including arranging a heap spray and accounting for build-specific offsets that vary with PHP versions, the C library and the container environment. At the time of disclosure, PHP's review of circulating proof-of-concept code found no working exploit, while CrowdStrike subsequently reported no successful exploitation in the wild or in its honeypots. These findings did not make the vulnerabilities harmless, but they did distinguish a remotely triggerable flaw from a reliable, broadly deployable exploit.

A long-standing problem, revisited

The underlying bug pattern had been identified as far back as 2004, when exploitation was considered impractical. An external audit by OSTIF and Quarkslab in 2024 raised related concerns again. A developer noticed the behaviour while addressing another issue and considered whether it might be exploitable, but no concrete exploitation path was established. Proposed fixes also caused compatibility problems, and the work stalled. The PHP Foundation later described this as a structural failure in how the issue had been handled.

The research that led to the 2026 disclosure built on that history. In August, a Calif researcher familiar with the earlier work used an AI model to help search PHP's source code for related patterns, identifying a vulnerable path through session upload progress. Wiz independently reached the same underlying flaws weeks later and identified additional vectors.

The significance is not that a model independently invented a new class of vulnerability. Previous researchers had already identified the underlying behaviour. AI-assisted analysis helped extend that work and find a practical exploitation path. The difficult remaining work, including chaining flaws and adapting an exploit to a target's memory layout, still required technical expertise. The episode nevertheless illustrates how research that once stalled for lack of a concrete exploit can become actionable when the cost of exploring related code paths falls.

The vulnerabilities' CVSS Attack Complexity rating of High is also relevant to how organisations interpret severity. It reflects the conditions required for successful exploitation, but does not mean the issue is unimportant or unlikely to be exploited eventually. At the same time, the history alone does not establish that the rating caused the earlier work to be deprioritised. The more defensible lesson is that a lack of demonstrated exploitation can leave technically serious problems unresolved when researchers cannot show a practical route from defect to impact.

Disclosure under pressure

The timeline helps explain why the response became contentious:

• 20 October, around 15:00 UTC: The two CVE identifiers appeared online alongside incorrect severity and release-date information. PHP brought the planned release forward by one day.

• 20 October, evening: A proof-of-concept demonstration video was published prematurely, intensifying efforts to reproduce the vulnerabilities.

• 21 October, 03:02 UTC: Cloudflare enabled Web Application Firewall rules to mitigate exploitation attempts.

• 21 October, 07:41 UTC: Chainguard published patched container images more than six hours before the coordinated release. PHP criticised the early availability, while Chainguard argued that exploitation was already under way.

• 17 October, reported retrospectively: Amazon disclosed that its MadPot honeypot had recorded an attempted exploit three days before the public leak. Amazon said it could not determine how the actor obtained the information during the embargo.

The pre-disclosure honeypot observation complicates any simple account of the leak as the starting point for attacker interest. It does not establish that the vulnerabilities were being successfully exploited, or explain how the actor obtained the relevant information. Likewise, the early availability of patched images created an opportunity for researchers and attackers to compare vulnerable and fixed code, but the evidence does not establish how much it accelerated exploitation.

The episode illustrates the difficulty of coordinating a disclosure once information begins to escape. Defenders need time to prepare mitigations and updates, while vendors and researchers must weigh the risks of releasing technical detail. An embargo can reduce that risk, but its effectiveness depends on information remaining contained and on participants coordinating their actions. PHP2Shell's timeline shows how quickly those conditions can change.

What the fix changes

PHP's fix, commit 01a40e89fb, changes how out-of-memory conditions are handled. Instead of immediately aborting execution through longjmp(), PHP records the memory-limit error and allows the current operation to return. A fatal error is then raised at a safe point, such as between virtual-machine opcodes, before zend_call_function(), after the main script or once request-body parsing has completed.

The change also retains a harder memory ceiling of approximately twice the configured memory_limit. If memory consumption continues to rise before execution reaches a safe point, the process can still be terminated. For the session-upload-progress path, PHP also prevents class resolution during the pre-request phase, blocking mechanisms such as autoloaders, __wakeup() and __unserialize() from running in that context.

The approach avoids removing longjmp() entirely, which could have introduced compatibility problems across PHP and its extensions. Instead, it changes when the error is acted upon and prevents potentially unsafe operations during the vulnerable request-processing stage. Having a concrete exploitation path gave developers a more specific basis for designing and assessing the fix than the 2024 investigation had provided.

The response and its costs

The initial response was shaped by two highly shareable facts: the vulnerabilities had CVSS scores of 9.2, and PHP runs a substantial proportion of the web. Headlines describing an internet-wide emergency spread quickly. Yet within days, CrowdStrike and WatchTowr were reporting that much of the circulating proof-of-concept material did not achieve reliable code execution.

That distinction matters for incident prioritisation. A high-severity vulnerability can warrant urgent patching even when reliable exploitation remains difficult, particularly when the affected component is widely deployed. But the urgency of remediation and the certainty of a successful attack are separate questions. Conflating them can make it harder for organisations to distinguish immediate evidence of compromise from precautionary work that is still necessary.

OX Security also reported a less visible consequence of the information vacuum: incomplete mitigations, AI-generated fixes containing errors and questionable detection scripts circulated on social media. This is a genuine risk during fast-moving disclosures, when defenders may be under pressure to act before reliable technical guidance is available. It does not mean early warnings were unjustified; it means the quality of the accompanying guidance matters as much as its speed.

Other developments during the same week offer useful context, though they are not direct equivalents. The PHP Foundation reserved CVE-2026-115560 for a separate remote-code-execution flaw that it described as requiring an unlikely combination of configuration and application code, and published mitigation advice rather than an emergency fix. GitLab issued a CVSS 10.0 fix covering a long history of releases, while the LiteLLM supply-chain compromise involved reported credential theft rather than a vulnerability awaiting exploitation. Their differing levels of coverage and response cannot be attributed to a single factor, but they underline how severity scores, practical exploitability, confirmed impact and public attention can diverge.

One week on

PHP2Shell is neither a story of mass exploitation proven by the available evidence nor a false alarm simply because reliable public exploits were initially scarce. The vulnerabilities exposed a long-standing weakness in core memory handling, and researchers eventually established practical paths that earlier investigations had not found. The response also showed how quickly disclosure timelines can shift, and how incomplete technical information can complicate defenders' decisions.

The enduring question is how to handle that uncertainty. Organisations need to act on serious vulnerabilities before widespread exploitation is confirmed, but they also need reliable distinctions between a theoretical weakness, a demonstrated exploit, observed attempts and verified compromise. PHP2Shell is a useful case study in why those distinctions should inform the response without becoming an excuse to delay it.