PHP2Shell: Two Critical Flaws In The Runtime Under The Application

The PHP project disclosed two critical flaws in the runtime itself, so updating an application does not remove them, and proof-of-concept activity appeared before the official release and spread immediately after it. Reports on exploitation differ, and no payload, victim count or actor has been published.

The Week's Signal

Two critical flaws, CVE-2026-109618 and CVE-2026-109619, sit in PHP, not in any application built on it. The PHP security team gave advance notice on October 20 of a release scheduled for October 21 at 14:00 UTC, and the fixes arrived earlier than that: CERT-EU's advisory records the release at 13:30 UTC. Both flaws are rated CVSS v4.0 score of 9.2. The PHP advisory says the risk is highest for Apache mod_php, "with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs."

Three things made the timing unusual. The PHP Foundation, as reported by The Record, says coordinated disclosure was on track until rumors appeared on social media two days before the release, and that it moved disclosure up by a day. Cloudflare told Krebs on Security it deployed WAF rules at 3:02 a.m. UTC on October 21, before the release. AhnLab's ASEC found "php2shell" repositories on GitHub within hours: its earliest relevant repository appeared on October 18 and the first one it classed as a proof of concept on October 20, with creation peaking on October 21.

CISA listed an alert dated October 21 and titled "Critical Vulnerabilities in PHP Require Immediate Patching." CERT-EU's advisory says only an update fully fixes the flaws and that, where immediate patching is not feasible, organisations should consider isolating internet-facing resources. Cybersecurity Dive reports that CISA and partner agencies issued similarly urgent guidance. CISA's page could not be retrieved for this issue, so this issue does not quote it.

The Incident Ledger

CVE-2026-109618. PHP uses longjmp() to abort a request when an allocation fails. If that happens while request memory is only partly initialized, the advisory says PHP does not handle the early exit correctly, and request shutdown can read or branch on invalid state. The advisory lists several multipart parsing issues that can trigger the out-of-memory condition within normal PHP limits, including missing content-length handling, unlimited headers per part, and empty file controls combined with nested field names. Reliability depends on the PHP build, extensions, frontend behavior and allocator layout.

CVE-2026-109619. PHP can retain error, session, object and extension state that points to memory owned by a finished request. Some operations that run before normal request initialization read that stale state, causing a use-after-free. Exploitation needs two requests on the same worker: a producer that leaves stale state, and a consumer that reads it. The advisory confirms two consumers, INI diagnostics before request initialization and session upload progress before session initialization. The PHP manual lists session.upload_progress.enabled as enabled by default. The one confirmed producer is the PHP 8.5 fatal_error_backtraces feature, and the advisory lists fatal errors, including memory exhaustion and execution timeouts, as general causes.

Affected versions. Both advisories list PHP below 8.2.35, 8.3.36, 8.4.27 and 8.5.12. PHP says 8.1 and older no longer receive updates from the project, that some distributions and long-term-support vendors provide backported fixes, and that it published source-only backports for 7.4, 8.0 and 8.1. NCSC-NL, citing CERT-EU, says PHP 5 and later may be affected and that earlier versions have not been assessed.

What has been observed. The reports differ, and each is the reporting organization's own:

• The Canadian Centre for Cyber Security's alert AL26-026, dated October 21, says no active exploitation had been identified at that time, that a proof of concept is available based on open-source reporting, and that the situation "can change quickly."
• SecurityWeek reports that several security companies saw first exploitation attempts around the time the patches landed on October 21, and quotes one of them saying it had not observed successful attempts to date.
• Cloudflare told Krebs on Security it had detected some exploitation and deployed WAF rules at 3:02 a.m. UTC on October 21. Krebs gives no volumes.
• Per SecurityWeek, another company reported exploitation at scale a few hours before the fixes shipped, mostly through PHP's session upload-progress path. SecurityWeek does not say whether any attempt succeeded.
• NCSC-NL's repository, in a status block marked "Last updated: 21 October 2026" and read on October 22, said NCSC had no indication of active exploitation but considered large-scale exploitation likely in the short term. The page is a living document and its status block may have changed since, so re-check it before relying on this line.

No payload, post-exploitation activity, victim count or actor has been published in the sources reviewed for this issue. Whether either flaw has been added to CISA's Known Exploited Vulnerabilities catalog was not verified for this issue, and this issue makes no claim either way.

Why This One Matters

The scale of what runs PHP. W3Techs reports that PHP is used by 69.3% of the websites whose server-side language it can identify, as of October 22. Censys figures relayed by Krebs on Security put about 2.58 million internet-facing hosts and 54.9 million web properties on PHP. Those numbers measure use of PHP. They do not say how many installations run an affected version, and no source reviewed for this issue gives that.

What the advisories separate. A critical score is not a guaranteed exploit: both flaws are rated High attack complexity, and the PHP project says reliability depends on the build and environment. A demonstrated exploit is narrower than the scope: mod_php is confirmed, while PHP-FPM is confirmed for only one of the two flaws. And an observed attempt is not an observed compromise.

Why a runtime flaw is a different kind of problem. The comparison below is our analysis, not a sourced finding.

The limits matter as much. The scope here is two flaws in PHP versions below the fixed releases. The advisories do not say every PHP site is exploitable, and this issue does not say so either. NCSC-NL's repository notes that products that embed or depend on PHP may also be affected.

A secondary effect is already visible. ASEC counted 99 of the top 100 non-fork "php2shell" repositories on GitHub as addressing the flaws, nearly all created on October 21, and counted 36 offensive repositories (proofs of concept and reproduction labs), with its data ending at 4:27 p.m. UTC on October 21. ASEC's article also refers to 27 proofs of concept elsewhere, so the two counts are inconsistent and this issue uses only the 36 figure. ASEC did not confirm malware in any repository. It warns that mitigation scripts run as root and that past campaigns have hidden malware in fake proofs of concept.

The Mechanism

The two flaws share a shape and differ in how they are reached. Both depend on PHP's request lifecycle: memory and state belong to a request, and cleanup assumes the state is valid.

In CVE-2026-109618, a single request can push a half-built request into an out-of-memory exit, and cleanup then acts on invalid data. In CVE-2026-109619, one request leaves state behind and a later request on the same worker reads it before it is reset. The second needs a long-lived worker and two requests. The first can be a single multipart request.

The figure below sets the two paths side by side, step by step, using only the steps the advisories state.

Analytical ATT&CK Mapping

This is an analytical mapping. The advisories and the exploitation reports assign no ATT&CK identifiers, so the ID here is ours. The technique name and tactic were checked against attack.mitre.org on October 22, 2026 (ATT&CK v20).

One row is all the sources support. Not mapped: execution, persistence, credential access or any other post-exploitation technique, because no source reviewed describes what an attacker did after a successful request. A web shell would be a natural inference and is not evidenced here.

The Prevention Gap

The PHP project is direct: "There are no complete mitigations, updating is the only safe choice." Its partial measures come with the caveat that they "do not make an installation safe." For CVE-2026-109618 they include setting memory_limit=-1 in a way applications cannot override, keeping post_max_size conservative, and enforcing request-size limits at the frontend. For CVE-2026-109619 they include session.upload_progress.enabled=0 and, on PHP 8.5, fatal_error_backtraces=0, each followed by a restart of all workers.

A version string is weak evidence. PHP notes that some distributions and long-term-support vendors provide backported fixes, so a version number alone does not settle the question and PHP points readers to their vendor. Installing a package does not by itself replace code already loaded by running workers, and a container image that was not rebuilt is still the old image.

Two gaps sit underneath the patching. The first is inventory. Asset records usually list applications and middleware, and often stop short of the runtime version beneath them. Without that line, a runtime flaw turns an update into a search. The second is lifecycle. A runtime that no longer receives project updates leaves the fix to a distribution or vendor, or to an upgrade that has to be planned. Both gaps are our reading of why this event is hard to answer quickly, not a claim from the advisories.

The harder question is the window. Companies report attempts before the fixes were public, so a server that faced the internet on an affected version before October 21 was exposed during a period when nobody had a patch. The patch does not say whether an attempt reached it. That evidence, if it exists, sits in web server and frontend logs, in unexpected child processes of the web worker account, and in files created under the web root. That is our reading of where to look, not guidance from the advisories.

What To Do Now

The order below is ours. The actions themselves come from the PHP advisories, CERT-EU and the Canadian Centre for Cyber Security.

First, get a clear picture of exposure (immediately). Find every PHP runtime and its version, including containers, base images and vendor products that embed PHP. Start with what is reachable from the internet, and confirm who maintains the PHP on each server. For systems that cannot be updated soon, CERT-EU says to consider isolating internet-facing resources from public networks until the fix is applied.

Second, update, restart and rebuild (within a day). Move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to a vendor package that states it contains the fix. Restart every worker and rebuild container images. Treat 8.1 and older as needing a vendor backport or an upgrade, and note PHP's statement that 8.2 reaches end of life on December 31, 2026. Where an update has to wait, the partial measures in The Prevention Gap are what PHP lists, with its caveat that they do not make an installation safe.

Third, review the window and build the record (within a week). For internet-facing PHP that was on an affected version through October 21, it is worth checking multipart requests with unusual structure, session upload-progress activity, worker restarts, web worker processes starting shells or script interpreters, and new files or scheduled tasks. The Canadian alert recommends reviewing web, application, authentication and endpoint logs. Preserve logs before cleaning anything. Then keep a PHP runtime inventory with a lifecycle date for each branch, so the next runtime event starts from a list.

Threat intelligence becomes operational when reported behavior can be tested. The PHP advisories describe where the flaws sit and which request shapes reach them, and the exploitation reports describe attempts against internet-facing servers. Our products play distinct roles in that process.

ORION™ provides threat intelligence to help teams understand relevant adversary activity. HELIOS™ helps discover and track internet-facing assets. Where a suitable PoC is available, APOLLO™ can safely validate exploitability and test how existing controls respond. ATLAS™ assesses control effectiveness across broader simulated behaviors. TARA AI orchestrates the CTEM cycle, connecting intelligence, exposure and validation findings to help teams prioritize and mobilize the next action.

Together, they help turn threat intelligence into an evidence-based cycle of discovery, validation and action. They do not replace vendor patches or determine whether a system was compromised before remediation. This issue does not claim that these flaws or the reported attempts are already represented in digiDations' validation library.

The advisories describe two flaws below the application, one demonstrated request that reaches a runtime before application code, and a patch window that began with attempts and no fix.