The new Heartbleed: PHP2Shell

Two critical vulnerabilities in PHP have forced an uncomfortable decision on organizations running web services: patch immediately, or consider temporarily removing exposed systems from the internet. The technical problems are deep inside the PHP runtime, but the incident is also a lesson in coordinated disclosure, patch distribution, and how quickly an infrastructure vulnerability can become a business continuity problem.

The vulnerabilities, CVE-2026-109618 and CVE-2026-109619, are both rated 9.2 under CVSS v4.0. The PHP project released fixes on 21 October 2026. The important question is not simply whether your website uses PHP, but which PHP runtime is actually serving requests, how it handles them, and how quickly you can replace it.

What will you learn from this article?

• How the two vulnerabilities differ at the memory-management level.
• Why application-level security controls may not protect the PHP interpreter.
• What went wrong during coordinated disclosure.
• How to distinguish exploit attempts from confirmed compromises.
• What infrastructure owners should do now, and what to improve before the next emergency.

Two bugs in the runtime, not in your application

CVE-2026-109618: out-of-memory corruption. PHP can terminate a request when its configured memory limit is reached. Normally that should produce a controlled fatal error. In this case, an allocation failure at the wrong moment could leave internal structures only partly initialized. Later cleanup could treat that invalid state as legitimate data and corrupt memory. The PHP Foundation reports demonstrated unauthenticated remote code execution on Apache with mod_php, including a path triggered before application code executes. PHP-FPM exploitation was also demonstrated through application-level paths.

CVE-2026-109619: stale state across requests. A fatal error could leave internal state referring to memory owned by an earlier request. Once that request ended, its memory was freed, but a later request processed by the same worker could access the stale reference. This is a use-after-free: code operates on memory whose original object no longer exists. The PHP Foundation reports a confirmed use-after-free and worker crash, as well as demonstrated remote code execution against a real-world application running on mod_php.

These are related failure modes, but they are not identical. The first breaks an initialization invariant: the runtime treats a structure as ready when it is not. The second breaks a lifetime invariant: a reference outlives the memory it points to. Both involve fatal-error paths, which are particularly difficult to reason about in a mature C runtime.

The distinction matters operationally. Updating WordPress, Drupal, or an application dependency does not fix vulnerable PHP engine code. And where the vulnerable path runs before the application starts, authentication or application-level input validation cannot be counted on as protection.

What AI-assisted research changes

The transition from a suspected memory-safety weakness to a demonstrated remote exploit can involve weeks of source-code review, hypothesis testing, and environment-specific debugging. AI-assisted security research may compress that cycle, helping researchers connect obscure error paths, reason about object lifetimes, and test exploitability faster, Wiz Research specifically says it used AI-powered research in uncovering PHP2Shell. See Wiz Research’s technical analysis and its research briefing.

The operational consequence is that defenders should not assume a long interval between a theoretical bug, a working proof of concept, and hostile activity. Amazon’s threat intelligence report says its honeypots recorded a PHP2Shell exploitation attempt on 17 October, before public disclosure, Amazon cautions that it could not determine whether those attempts would have succeeded against real-world systems.

Why the disclosure became part of the incident

The PHP Foundation says the problem behind the out-of-memory vulnerability had been suspected since 2024, but the practical impact became clearer in 2026. Multiple research teams, including teams using AI-assisted tools, contributed findings. This is not proof that AI alone discovered or exploited the vulnerabilities, it does show that maintainers increasingly face a high volume of sophisticated security reports.

The coordinated release was originally planned for 22 October. On 20 October, the CVE identifiers appeared online ahead of schedule, initially without technical details. The project moved the release forward to 21 October at 14:00 UTC. A security firm’s proof-of-concept video was then mistakenly published and circulated, revealing limited additional information. On 21 October at 07:41 UTC, Chainguard published images containing the fix before the coordinated release.

Why does publishing a fix early matter? A patch is also information. Someone can compare patched and unpatched code or binaries to identify the vulnerable behavior. If only one supplier has released an update, attackers may be able to study it while other users still cannot install a supported fix. Conversely, releasing before downstream packages are ready can leave organizations without a practical upgrade path. Coordinated disclosure is an attempt to reduce that mismatch, not merely to preserve secrecy.

Are attacks actually succeeding?

Reports of scanning, malicious requests, honeypot hits, and working laboratory demonstrations are important, but they are not interchangeable with evidence that an identifiable production organization has been compromised. A proof of concept establishes technical exploitability, an attack attempt establishes hostile activity, a confirmed breach requires additional evidence.

As of this draft, the sources reviewed here establish successful researcher demonstrations and observed in-the-wild exploitation attempts, but they do not identify a specific, independently verified victim whose production environment was compromised through either CVE. Organizations should not wait for a public victim report before patching.

Public exploit code

One publicly available GitHub proof-of-concept repository for PHP2Shell is available here.

Why would a website be taken offline?

If an internet-facing service is exposed and a fix cannot be deployed safely, temporarily disabling that service can reduce the immediate attack surface. This is a costly decision: availability is itself a security and business requirement. Public-service operators may need to weigh interruption against the risk of compromise, data theft, or persistent attacker access.

A precautionary shutdown is not evidence of a successful intrusion. It can be a deliberate containment choice while teams inventory deployments, patch systems, restart workers, and investigate suspicious activity.

What should organizations do now?

Identify the runtime, not just the application. Inventory PHP versions across hosts, containers, managed platforms, scheduled jobs, and web-server integrations. Confirm what is running in production rather than relying only on package manifests.

Upgrade to a fixed release. The PHP project identifies 8.2.35, 8.3.36, 8.4.27, and 8.5.12 as patched versions. PHP 8.1 and older branches are end-of-life and require migration to a supported branch or a properly supported vendor solution. The project says there is no complete configuration-only mitigation.

Verify deployment. Rebuild and redeploy images where necessary, restart long-lived PHP workers, check that the effective runtime version changed, and retest important application paths. A downloaded package is not the same thing as a remediated service.

Investigate exposure. Preserve relevant web-server, WAF, application, and host telemetry. Review suspicious requests, unexpected worker crashes, and post-exploitation indicators. Avoid treating every scanner hit as a breach, but do not assume the absence of an alert proves safety.

Prepare a fallback decision. Decide in advance who can authorize temporary service isolation, how customer-facing communications will work, and what evidence is needed to bring a service back online.

The bigger lesson: coordinated disclosure needs coordinated deployment

This incident highlights three clocks running at different speeds: researchers uncover technical details, maintainers and distributors prepare fixes, and operators deploy them. An embargo can help align the first two, but it does little if the third takes days. Equally, an early binary release can create a patch-diffing opportunity while other users wait.

A mature response therefore needs more than a vulnerability inbox. It needs trusted downstream coordination, an emergency release trigger, accurate asset ownership, rehearsed patch deployment, and a way to assess whether a service should remain available while exposed.

At Naunet, we view this as an architecture and resilience question as much as a vulnerability-management question. A focused assessment can help identify which public-facing systems depend on a vulnerable runtime, where compensating controls do and do not apply, and how quickly an organization can validate remediation. The objective is not simply to close a CVE ticket. It is to reduce the time during which an attacker can turn a runtime flaw into business impact.

Sources

• PHP Foundation, Today’s PHP Security Release, and How We’re Strengthening PHP Security (21 October 2026)
• PHP 8.5.12 release announcement
• Google Cloud, Responding to core PHP vulnerabilities (21 October 2026)
• NHS England Digital, Critical Vulnerabilities in PHP (21 October 2026)
• Wiz Research, PHP2Shell: AI uncovers critical RCE vulnerabilities (21 October 2026)
• Wiz, PHP2Shell technical threat briefing (21 October 2026)
• Amazon Threat Intelligence, PHP2Shell exploitation attempts before disclosure (21 October 2026)
• GitHub, eness PHP2Shell proof of concept (third-party)
• GitHub, wakemeiflose PHP2Shell lab and proof of concept (third-party)