PHP2Shell: how a failed request poisons the next one

Section 01Executive Summary

On 21 October 2026 the PHP project shipped emergency fixes for two critical flaws, CVE-2026-109618 and CVE-2026-109619, that let an unauthenticated attacker run code on a web server by sending requests PHP processes before any application code runs.^{[1][2][6][26]} Both are rated CVSS v4.0 9.2.^[1][2] The fix was planned for 22 October; the identifiers leaked on 20 October and the release was pulled forward a day.^[7][15]

Most coverage so far repeats the headline, the version numbers and “patch now”. That advice is right, but it leaves the interesting questions unanswered. How does running out of memory become code execution? Why do PHP and the researchers describe the two CVEs differently? What does each way of running PHP change? Which of the mitigations people reach for first do not work at all? How much of the exploitation news is evidence and how much is claim? This report works through those questions, with a source for each statement.

The core idea fits in two sentences. PHP gives every request a block of memory and, when a request dies in the middle of its work, jumps out through an emergency exit that skips the tidy-up steps.^[1][11] If a pointer to that memory was already published, or a structure was only half built, something later in the same worker process trusts what is left behind.^[1][2][3]

Key takeaways

1. 01
   This is one bug class showing up in several places, not two isolated typos.

   Both advisories describe state that is half-built or dangling when a request is interrupted. The discoverers found the same “publish, do fallible work, commit” pattern at several points in the engine, which is why the fix is a change to how PHP fails rather than a one-line patch.^[1][2][3]

2. 02
   The hardening reflexes administrators reach for first mostly do not work.

   Hiding errors, setting values with ini_set() or .user.ini, process address-space limits and container memory limits either act too late or push PHP onto the vulnerable path. PHP states that there is no complete generic configuration mitigation.^[2][1][6]

3. 03
   Patch and restart is the only complete fix, and the fix changes how PHP handles out-of-memory.

   The patch removes the emergency jump on out-of-memory and replaces it with a delayed soft stop and an immediate hard stop at a higher threshold. After patching, every worker must be restarted and the binary that actually serves requests must be verified.^[1][9]

4. 04
   Apache mod_php is the worst case; PHP-FPM is conditional, not safe.

   Under mod_php the demonstrated attack runs before application code. FPM kills its child process on a failed startup, which blocks that one sequence, but the PHP Foundation says code execution was confirmed on FPM through application-level code paths, and session-lifecycle execution was validated under suitable application conditions.^{[1][2][3][6][28]}

5. 05
   The real exposure is the long tail.

   Branches 5.4 to 7.3 get no fix from the PHP project and 7.4 to 8.1 get source-only backports. PHP also hides inside hosting panels, vendor appliances, Windows software and forgotten internal apps.^[7][8][16]

6. 06
   Exploitation is under way, and it began before the patch.

   Amazon says its honeypots saw an exploitation attempt on 17 October, four days before disclosure, and that PHP2Shell is now broadly exploited. Cloudflare’s chief executive says attempts rose from thousands in the ten hours before the announcement to millions by the next morning. CISA said when it published that it had not observed exploitation, and no compromise had been publicly confirmed, so the open question is how many attempts succeeded.^[38][49][37]

7. 07
   AI shortened the path from idea to exploit, and the disclosure process broke under it.

   Both discovering teams credit AI models for variant analysis and for adapting exploits across PHP versions; these are vendor-reported claims, but they match each other. The embargo then failed three ways within a day: leaked identifiers, an accidentally published demonstration video, and a distributor that released patched images more than six hours early.^{[3][4][28][31]}

8. 08
   Governments treated it as an emergency and said so in public.

   The prime ministers of Japan and the Netherlands, Canada’s minister of artificial intelligence and digital innovation, the US National Security Agency, the UK National Cyber Security Centre, CISA and CERT-EU all told organisations to prepare, patch immediately or take unpatchable systems offline, and government sites went dark in at least nine countries.^{[44][58][51][45][46][37][29][17]}

Section 02PHP2Shell at a Glance

Three patterns stand out. First, the gap between leak and patch was about a day, and attack traffic reportedly started inside it: a defender’s usual “wait for the patch, then schedule it” rhythm did not apply.^[5][14][24] At 07:41 UTC on release day a distributor published patched images more than six hours before the coordinated release, a fact both it and the PHP Foundation confirm.^[28][31] Second, the response was availability-first. Governments and large sites chose to switch services off rather than run exposed, which is unusual and tells you how the risk was read.^[17][5] Third, the exploitation picture moved quickly: some vendors saw nothing while others described attacks at scale, the PHP team found no functional exploit at release, and by 22 October Amazon reported an attempt dating to 17 October while Cloudflare’s chief executive reported millions of attempts.^{[14][8][11][7][38][49]} Section 11 sets out each claim and its source.

Section 03Why It Matters: Exposure and Blast Radius

Estimates of PHP’s share of the web range from about 70% to nearly 75% of sites whose server-side language is known.^[15][16][4] That figure is easy to quote and hard to act on, because the exposure sits in many different places. The vulnerabilities are in the PHP engine, so patching WordPress, Drupal or Magento does not fix them and a hardened custom application is as exposed as a default install.^[4][16]

What was actually demonstrated

Calif reports unauthenticated remote code execution against a long list of PHP applications: WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel and Symfony, with WHMCS in some cases, and arbitrary-script code execution in some configurations. It says the exploitable paths work under default settings.^[3] Wiz tested the stock wordpress:latest, drupal:latest and joomla:latest container images and reports unauthenticated code execution against each, plus a separate memory-disclosure path that does not need code execution at all.^[4] Both are the discoverers’ own claims, and they agree with each other.

Two practical traps follow. Distribution builds often keep an older upstream version number while carrying the fix, so php -v alone can mislead; the vendor advisory is the reference.^[9] And the PHP binary on your command-line path is often not the one serving requests, so a host can look patched while its web workers are not.^[9] Linux distributions and long-term-support vendors received patches before the public release, and advisories already exist for Red Hat, Gentoo, Fedora and Ubuntu.^[9]

How big is the unpatched tail?

Counts of exposed PHP are estimates from different methods. VulnCheck found PHP on 2,608,039 internet-facing hosts, over 700,000 of them on 3.x to 7.3, about 400,000 on 7.4, 8.0 or 8.1 and about 403,000 on the supported 8.2 to 8.5 branches.^[38] A VirusTotal analysis relayed by The Record found 5.1 million IP addresses running PHP, at least 758,000 of them on end-of-life versions and 85,000 on the latest pre-patch releases; the article stresses these show internet footprint, not confirmed vulnerable systems.^[32] Zafran counts about 1.5 million internet-facing hosts advertising a PHP version, with more than half on 8.1 or older.^[35] Cisco Talos is reported to estimate that roughly half of vulnerable PHP systems may never receive a patch.^[32] A live blog adds that about 18% of WordPress sites and 24% of Joomla sites reportedly run 8.1 or older, a figure not traced to a primary source. AhnLab estimates that about 110,000 Korean hosts ran vulnerable versions before the patches, the sixth-highest count worldwide.^[40][34] Earlier estimates put potentially vulnerable exposed hosts between 1.3 million and 1.9 million, from two different methods that were never reconciled.^[7] The numbers disagree on size but agree on direction: a large share of exposed PHP sits on branches that get no upstream fix.

Section 04The Engine in One Page

A PHP worker is a long-lived process that handles request after request. How it is wired to the web server is called its SAPI: Apache’s mod_php runs PHP inside the Apache worker; PHP-FPM keeps a pool of child processes behind nginx or Apache; php-cgi, FrankenPHP and LiteSpeed’s LSAPI are other arrangements.^[1][2] For every request the worker runs startup (apply per-request settings, parse the incoming body), then your application, then shutdown (clean up).^[2] Startup and shutdown are engine code that you did not write and cannot patch.

Each request gets its own heap, and PHP frees that heap when the request ends.^[2] A configurable ceiling, memory_limit, stops one request from eating the machine. When an allocation would cross it, PHP does not return an error to the caller. It performs a bailout, a longjmp() to an error boundary, which is fast but skips every step between the failure and that boundary.^[1][11]

The pattern behind both bugs

Calif’s research reduced the problem to a pattern worth memorising: state is published or destroyed, fallible work follows, and a fatal error skips the commit or rollback step.^[3] If PHP stores a pointer in a global before the risky part, the cleanup that would clear it never runs when the risky part dies. If it increments a counter before allocating the thing the counter describes, teardown later trusts a count that is ahead of reality.^[3]

Two properties make this attractive to an attacker. The ceiling is predictable: the default heap limit is 128 MiB, so a request can be shaped to fail at a chosen moment.^[3] And the dangerous parsing happens early. Sansec notes that every known trigger is a multipart/form-data request, which PHP parses before the application can say no.^[5][3]

Section 05CVE-2026-109618: When Running Out of Memory Is the Attack

PHP’s advisory describes the mechanism in three sentences. In some contexts request memory is briefly reachable before it is fully initialised. If an allocation fails inside that window, the bailout leaves the structure half-built. Request shutdown then reads or branches on that memory, and the failing allocation does not have to be related to it.^[1]

How a request under the limits still exhausts memory

The obvious defence, a small post_max_size, turns out to be weaker than it looks. The advisory and Calif list several ways to push memory use past memory_limit with a body that looks small:^[1][3]

Calif adds a detail about one interruption point: a hash-table insert increments its counters before allocating the key, so a failure at that moment leaves a visible but uninitialised entry that teardown later processes.^[3]

Why the SAPI decides the outcome

Under mod_php, request shutdown runs even when startup failed, so the engine tidies up a structure that was never finished, before any of your code has had a chance to refuse the request.^[1] Under PHP-FPM, a failed startup makes the child exit and the damaged state disappears with it.^[1][3] Calif’s FPM route therefore needs a fatal after a successful start, aimed at the bookkeeping used when decoding serialized data; it reports application-dependent code execution there too, and the PHP Foundation’s postmortem says RCE was confirmed on FPM through application-level code paths.^[3][28]

What the patch changes

The fix removes the longjmp() on out-of-memory. PHP now raises a delayed “soft” out-of-memory condition at the next safe point in the virtual machine, which lets it stop gracefully, and an immediate “hard” stop through _exit() if usage reaches a second, higher threshold. Shutdown no longer sees invalid state and normal memory_limit enforcement is kept.^[1] One operational consequence is worth testing before you rely on it: at the hard threshold the worker can end immediately, skipping shutdown handlers.^[9]

Impact. Unauthenticated code execution with the privileges of the web worker account, not necessarily root. Reliability depends on the PHP build, extensions, front-end behaviour and memory layout, which is why the CVSS vector rates attack complexity high.^[1][6][11]

Section 06CVE-2026-109619: One Request Poisons the Next

The second CVE is a use-after-free across requests. Workers persist, and some of their global state is meant to be reset at the start of each request. If an earlier request published a pointer to its own memory and then died before the reset, the pointer outlives the memory it points to.^[2] The advisory lays it out as producer, free, consumer. The Foundation’s postmortem adds that a use-after-free and worker crash were confirmed and that code execution was demonstrated against a real application on Apache mod_php:^[2][28]

Four families of stale state

Producers and consumers

Producers are anything that interrupts a request before its reset: parse or compile failures, uncaught errors, a failed require, an out-of-memory fatal, or “Maximum execution time exceeded”. A timeout counts as a fatal error, so any slow path an attacker can reach is a producer, and changing the timeout alone does not help.^[2]

Consumers are operations that touch the stale state before startup resets it. The advisory confirms two. The first is an INI diagnostic: a warning, notice or deprecation raised while per-request settings are applied, which does not need to be displayed or logged. Deprecated settings, an invalid memory_limit, date.timezone, an open_basedir-rejected path or a malformed number all qualify.^[2] That is why @, display_errors=0 and error_reporting do nothing: they hide the message, not the event.^[2] The second consumer is session upload progress.^[2]

Where per-request settings come from decides who is exposed. Under mod_php, .htaccess and php_value/php_flag/php_admin_* directives apply before php_request_startup() and can act as early consumers; ordinary php.ini is read at startup and not re-applied. Under FPM, pool values apply at worker start and .user.ini after normal initialisation, so neither provides the early window, but a front end that passes PHP_VALUE or PHP_ADMIN_VALUE that triggers an early diagnostic does.^[2]

The bug is not in your application. That is exactly why your application cannot fix it.Omar Babba

Section 07Reconciling the Descriptions

If you read only PHP’s advisories, CVE-2026-109618 is the out-of-memory corruption and CVE-2026-109619 is the stale global state.^[1][2] If you read the Wiz and Sansec material, CVE-2026-109618 is described as an upload-progress unserializer use-after-free with a memory-disclosure side effect, and CVE-2026-109619 as a fatal-error backtrace use-after-free plus an OPcache type confusion.^[4][5] Imperva classifies both as CWE-824, while PHP lists several weakness classes for them.^[11][1][2]

The two readings are not necessarily contradictory: the researchers describe primitives they chained, while PHP describes the root cause classes it fixed. In practice nothing depends on the mapping, because both CVEs are fixed in the same releases. Use PHP’s advisories as the authority on classification, and treat any researcher mapping of “primitive to CVE” as informative rather than definitive.

Names and mechanisms are as described in the researchers’ write-ups.

Section 08SAPI Matrix

Read the matrix as an ordering of urgency, not a list of safe configurations. “No exploit shown” means exactly that, and PHP’s guidance is to treat every SAPI that serves web requests as at risk.^[7][6]

Section 09How This Was Found: Twenty-Two Years and a Few Weeks

The first memory-limit remote vulnerability in PHP was disclosed by Stefan Esser in 2004, who withheld his exploit; two commercial vendors reportedly built private ones and the public “exploits” that circulated were fakes.^[3] In 2020 bug #78876 reported that very long variables in multipart bodies could cause out-of-memory conditions and leave temporary files uncleaned. A commenter in the community thread explains that the fix stopped a negative-length cast and did not add cleanup on allocation failure.^[3][19] In 2024 PHP had its first external security audit in years, funded by the Sovereign Tech Agency, organised through OSTIF and performed by Quarkslab. While fixing an issue the audit reported, a contracted core developer found the first signs of the out-of-memory problem. An exploit was theorised but no concrete route was found, and the fixes on the table each had a cost: a backward-compatibility break, new denial-of-service potential, or changes to many third-party extensions that seemed hard to coordinate. The consensus-based security team could not choose, and the work stalled and restarted for months. The Foundation calls this a structural failure of process and resources.^[28][3][33] The pattern repeats: a resource-exhaustion bug, judged low impact, left room for the next researcher.

Three reporters, one fortnight

1. 130 Jul. Calif joins OpenAI’s “Patch the Planet” initiative; the PHP Foundation is involved through Volker Dusch.^[3]
2. 21 Aug. First out-of-memory fatal and first interruption point found.^[3]
3. 311 Aug. Calif reports the first bug to PHP; OpenAI independently reports the same root cause the same day. Coordinated disclosure begins.^[3][28]
4. 414 Aug. Code-execution proof of concept shared with PHP.^[3]
5. 515 Aug. PHP confirms the proof of concept works.^[3]
6. 621 Aug. Calif reports a second bug.^[3]
7. 718 Sep. OpenAI reports further attack vectors.^[28]
8. 819 Aug. Wiz finds its first PHP vulnerability.^[4]
9. 920 Aug. Wiz confirms unauthenticated RCE against Drupal.^[4]
10. 1021 Aug. Wiz confirms unauthenticated RCE against WordPress.^[4]
11. 1124 Aug. Wiz reports further attack vectors to the PHP security team.^[4][28]
12. 1221 Sep. PHP acknowledges Wiz’s reports and begins a coordinated fix, per Wiz.^[4]
13. 1320 Oct. Details leak.^[5][15][28]
14. 1421 Oct. Patched releases and public disclosure.^[1][2]

Calif’s researcher also publicly posted a hash of one finding on 5 August, a standard way to timestamp a discovery without revealing it.^[3][57] Three independent reporters, Calif, OpenAI and Wiz, reaching the same bugs within thirteen days of each other is itself a finding: it suggests the bugs were findable by anyone who asked the right question, which raises the odds that others, including attackers, asked it too.

The role of AI

Both teams describe AI as part of the method, and their accounts are consistent. Calif says an LLM helped identify ways to reach memory_limit on demand, and an audit agent reviewed the memory manager, fatal-error reporting and request shutdown for places where an interruption could leave inconsistent state. Those findings were generalised into a reusable skill file that hunts the “publish, fallible work, skipped commit” pattern.^[3] Calif stresses that human knowledge of PHP’s vulnerability history was needed to steer the model, because default variant analysis favoured newer, more prominent bugs over obscure older primitives.^[3] Wiz says it used several frontier models, credits one of them with contributions to discovery, exploit development and patch validation, and claims one researcher did in a week what would previously have taken a world-class team months.^[4]

What PHP is changing. Since 1 July the security team has published 15 CVEs and triaged more than 100 reports that were invalid, duplicates or not reproducible. It says AI helps validate and group reports but people make every decision and write every patch. It created an Ecosystem Security Team in May, is moving from consensus to majority decisions, and has asked companies, hosting providers and governments for sustained funding. The Foundation itself used AI tooling: an earlier AI-assisted scan and OpenAI’s Daybreak Red for validating reports and exploits.^[28][33]

OpenAI’s account. OpenAI says Calif identified a critical flaw using GPT-5.6 Sol under its Patch the Planet initiative, with Wiz independently discovering and reporting both vulnerabilities, and that it led a coalition of maintainers, researchers and security providers for two months. It says it briefed US government bodies including the Office of the National Cyber Director and CISA, released a Codex skill that checks PHP versions, committed $1 billion in subsidised access for frontline defenders, and proposed a five-stage framework for responding to critical vulnerabilities. It also asked when, if ever, governments should patch systems they are authorised to manage, and floated internet-wide scanning that notifies owners or patches vulnerable systems.^[39][48]

Section 10The Disclosure: Sixty-Six Hours Around the Release

The plan was a coordinated release on Thursday 22 October at 14:00 UTC, according to the PHP Foundation; watchTowr’s account put it an hour later.^[28][8] PHP had reserved the right to release earlier if details became public or exploitation appeared.^[27] Then it came apart in four steps: three failures and PHP’s response.

The identifiers leaked. At about 15:00 UTC on 20 October the two CVE identifiers appeared on forums and social media with a wrong release time and a wrong CVSS score of 10.0, and no technical details.^[28] A Hacker News post was the visible source and was later deleted; the Foundation does not say who leaked the information.^[15][28] watchTowr confirmed on social media that the CVEs were real.^[15]

PHP moved early. At about 19:30 UTC PHP published its pre-announcement and brought the release forward from 22 October to 21 October at 14:00 UTC, because distributors were still packaging the fix.^[28][27] CERT-EU published advisory 2026-018 on 21 October.^[29]

A researcher’s video got out. At about 20:00 UTC Calif mistakenly published a video of its proof of concept working against several targets. It was deleted, but copies spread, and the Foundation says the video helped accelerate public proof-of-concept development.^[28] Tenable describes a third party sharing it and crediting Calif; the Foundation’s account is that Calif published it.^[7][28] From about 23:00 UTC, mitigation advice given to a few critical-infrastructure providers may also have leaked.^[28]

A distributor released early. At 07:41 UTC on 21 October Chainguard published built container images containing the fix, more than six hours before the coordinated release.^[28][31] The next subsection covers it. PHP then shipped 8.5.12, 8.4.27, 8.3.36 and 8.2.35 at about 13:30 UTC (CERT-EU and Huntress); other sources give times from 12:59 to 13:52, and the advisory timestamps cited by the encyclopedic summary say 13:34.^{[29][8][18][30][34]} Minimal source backports for 7.4, 8.0 and 8.1 appeared around the same time.^[26][34] Wiz announced at 13:32 UTC, its researcher Sagi Tzadik followed at 13:38 and Calif at 13:53, while LCFR, whom Calif names as the hacker who discovered the flaw, posted a demonstration video of an exploit running against WordPress.^{[56][55][54][53]}

1. 120 Oct, ≈15:00. The CVE identifiers leak with a wrong release time and a wrong 10.0 score.^[28]
2. 220 Oct, ≈19:30. PHP publishes its pre-announcement and brings the release forward to 21 Oct at 14:00.^[28][27]
3. 320 Oct, ≈20:00. Calif mistakenly publishes a demonstration video; it is deleted but copies spread.^[28]
4. 421 Oct, 07:41. Chainguard publishes patched images more than six hours before the release.^[28][31]
5. 521 Oct, ≈13:30. PHP ships the fixes (CERT-EU and Huntress; other sources 12:59 to 13:52).^{[29][8][30][34]}
6. 622 Oct, 14:00. The original release time, never used.^[28]
7. 721 Oct, from 07:34. Patchstack hears from hosting partners about active exploitation incidents; its own telemetry at 13:57 shows probing only.^[25]
8. 821 Oct, 07:43. Cloudflare reportedly sees early attack traffic (Sansec’s account, two minutes after marker 4; the sources do not link them).^[5]
9. 921 Oct, before release (approximate). Hadrian says PHP2Shell is exploited in the wild at scale, mostly via session upload progress. A single-vendor claim with no counts.^[14]
10. 1021 Oct, around release. watchTowr says first attempts hit its sensors and none has succeeded.^[14][12]
11. 1121 Oct, 20:30. Huntress reports no exploitation on its partner systems.^[8]
12. 1221 Oct, 03:02. Cloudflare’s protections go live for all customers, including free plans.^[24]
13. 1321 Oct, before release (approximate). CERT-EU advisory 2026-018 and the UK NCSC alert urge preparation and isolation; CERT-EU updated its advisory after the release.^[29][34]
14. 1421 Oct, 17:00. The Czech national government website is taken offline.^[17]
15. 1521 Oct (all day). Government and large sites in Germany, France, Belgium, the Netherlands and Finland go offline; Wikimedia takes services down.^[17]

Chainguard’s early images: confirmed, and contested

The PHP Foundation’s postmortem says Chainguard broke the embargo by publishing patched images more than six hours early while other distributors were still preparing. It calls the release unilateral, says it disregarded weeks of coordinated work, and says attackers could study the fix in binary form before most users could patch.^[28][31] Chainguard’s chief executive has said he made the call because exploits were hitting in the wild, that the company had independently found the bug and notified the coordination group right after deciding, and later apologised for the stress on maintainers.^[31][32] He told The Register that Chainguard heard from one of the researchers on the Friday that something was coming in PHP and that evening found the same flaws with its own AI tooling.^[43] ELLIO, a threat-intelligence firm, reports the first PHP2Shell request at its sensors at 08:36 UTC on 21 October, less than an hour after the images appeared; the sources do not say whether the two are linked.^[38] He cited exploitation reports from other vendors on the Tuesday night; no vendor or evidence was named.^[31] Chainguard’s published policy allows shortening timelines for active exploitation, and the Foundation answers that the policy’s criteria do not show PHP authorised publication.^[31] The two sides agree on the facts, the images and the time, and disagree on whether it was justified. The general lesson holds either way: when many distributors, hosts and vendors hold a patch in advance, the embargo’s weakest link is the number of people who hold it.^[28]

Section 11Exploitation: What Is Evidence and What Is Claim

What the evidence shows

By 22 October the public record had moved beyond research exploits. Amazon reports an attempt dating to 17 October and broad exploitation since, Cloudflare counts millions of attempts, and scanners with a distinctive user-agent were hitting honeypots.^[38][49] What the record does not yet contain is a named victim or a confirmed successful compromise, and CrowdStrike’s point that exploitation leaves almost no trace means the absence of reports is weak comfort.^[38] The three earlier engine-level PHP code-execution flaws, CVE-2012-1823 and CVE-2024-4577 in PHP-CGI and CVE-2019-11043 in PHP-FPM, are all in the CISA Known Exploited Vulnerabilities catalogue, and two have known ransomware use.^[7] If PHP2Shell follows that trajectory, exploitation becomes routine once a reliable public tool exists.

Section 12Impact

Technical impact

Code execution as the web worker. That is typically the web server or PHP-FPM account rather than root, but it is enough to read application secrets, database credentials and uploaded data, plant a webshell, and pivot.^[11][8] Rapid7’s vector rates confidentiality, integrity and availability impact all high.^[6]

Memory disclosure without code execution. Wiz and Sansec describe a path where heap contents come back in a PHPSESSID cookie, even if the application never starts a session. Sansec compares it to Heartbleed and lists passwords, session tokens, API keys and TLS private keys as possible contents.^[4][5] Treat the TLS claim cautiously: what can leak depends on what shares the worker’s heap, and the sources do not quantify it. The practical point is that a successful probe may leave no webshell and no file change, only a request that looked odd.^[5]

Availability as a side effect. The very mitigation PHP recommends for CVE-2026-109618, removing the memory ceiling, lets a single request consume the machine’s memory, so the interim fix creates its own denial-of-service risk. Sansec says to monitor memory and restore the limit after patching.^[5][9]

Operational impact: the day the web went dark

On 21 October a number of organisations chose to switch services off instead of running exposed. The Reuters factbox, which describes itself as partial, lists the first group below, almost all of them official statements relayed by Reuters;^[17] the last rows come from other reports.

Other reports add Dutch news and security sites, the Dutch House of Representatives and the national cyber security centre itself. Patchstack lists the Dutch DigiD and MijnOverheid services and several Japanese services, and a live blog says two underground forums went offline and large Japanese platforms entered emergency maintenance.^[5][25][34] US agencies are reported to have advised taking systems offline if they could not be updated, and Newsweek reported no evidence that US federal sites were compromised or taken offline.^[20][21] Guidance from the NSA, the UK NCSC, CISA and CERT-EU converged on the same advice: patch immediately, and isolate or take offline what cannot be patched, with CISA adding that anything on PHP 8.1 or earlier should come down until fixed.^{[13][15][20][21][22][29][37][45][46]}

Business impact

For most organisations the cost will not come from a breach but from the response: emergency change windows, outages by choice, unplanned platform migrations for end-of-life stacks and supplier chasing. Governments taking services offline pre-emptively over a runtime vulnerability is unusual. E-commerce and hosted-service operators carry the sharpest tail risk, because the same engine fault gives an attacker the web tier, the payment pages and, on shared hosting, possibly neighbouring tenants.^[16][8]

Section 13The Announcements and the Public Reaction

The researchers announced within about twenty minutes of the release: Wiz at 13:32 UTC, its researcher Sagi Tzadik at 13:38 and Calif at 13:53.^[56][55][54] The screenshots below were captured on 22 October; counts are as shown then, and times are UTC.

The announcements

The hacker Calif names as the discoverer

LCFR @lcfr_hax

His announcement: a screen recording of an unauthenticated exploit against WordPress 7.1.3, posted as a quote of Calif’s write-up. Calif’s own account describes him as the hacker who discovered php2shell, and PHP’s advisories credit a matching handle, lcfr-hax.^[53]

Posted 21 Oct (pinned) · 82K views · 106 reposts · 1.1K likes · View on X

Security firm that reported the flaws to PHP

Calif @calif_io

Calif’s announcement, “php2shell: a tale of two PHP remote vulnerabilities”, linking to its write-up and carrying the comic-style artwork that illustrates it.^[54]

Posted 13:53 UTC, 21 Oct · 126K views · 219 reposts · 624 likes · View on X

Wiz Research

Sagi Tzadik @sagitz_

Opened a thread with “Today we disclose PHP2Shell”: pre-authentication code execution shown against WordPress, Drupal and Joomla, plus remote memory disclosure from any PHP application, with a screenshot of the exploit tool in action.^[55]

Posted 13:38 UTC, 21 Oct · 407K views · 522 reposts · 2.7K likes · View on X

Cloud security company

Wiz @wiz_io

The company’s own announcement, calling PHP2Shell a decade-old core vulnerability reaching CVSS 9.2 and affecting 70% of the internet.^[56]

Posted 13:32 UTC, 21 Oct · 64.1K views · 116 reposts · 403 likes · View on X

Earlier: the 5 August hash post

LCFR @lcfr_hax

A post containing nothing but a hash. Calif’s account says a researcher published a hash of one finding on 5 August, a way to timestamp a discovery without revealing it; the post gathered more than half a million views.^[57]

Posted 16:54 UTC, 5 Aug · 567.6K views · 93 reposts · 1.1K likes · View on X

The patch then landed in the middle of a working day in Europe and the middle of the night in Japan, and the official response was unusually public. Japan’s prime minister posted a call to act that drew more than 75 million views, against about 10 million for the NSA’s warning and just under one million for the UK National Cyber Security Centre’s.^[44][45][46]

Governments and officials

Prime Minister of Japan

Sanae Takaichi @takaichi_sanae

Asked operators to act that night: check whether public sites use PHP, be ready to apply the patch due at 23:00 Japan time, and consider temporarily suspending a website if patching was not possible. The post was written in Japanese and is shown here in X’s automatic English translation; it also pointed to the national cyber office’s account.^[44]

Posted 12:55 UTC, 21 Oct · 75.9M views · 100K reposts · 339K likes · View on X

Prime Minister of the Netherlands

Rob Jetten @MinPres

Said the cabinet was closely following the PHP vulnerabilities and repeated the national cyber security centre’s advice to install the patch at once and keep vulnerable systems offline until then; DigiD and MijnOverheid would return as soon as that could be done safely. He quoted the Justice and Security Minister’s post relaying the same advice. The post is shown in X’s automatic English translation of the Dutch original.^[58]

Posted 15:40 UTC, 21 Oct · 79.3K views · 86 reposts · 452 likes · View on X

Canada’s Minister of AI and Digital Innovation

Evan Solomon @EvanLSolomon

Said some Government of Canada websites were taken offline as a precaution on the Canadian Centre for Cyber Security’s guidance, called PHP a global issue, and promised to restore affected sites once patches were applied.^[51]

Posted about 17:21 UTC, 21 Oct (edited) · 100.4K views · 424 reposts · 1.1K likes · View on X

US Representative, Massachusetts 3rd District

Lori Trahan @RepLoriTrahan

Quoted the NSA’s warning, said attackers began exploiting the flaws before the fix and that many sites run versions too old to receive it, and used the incident to argue for the FRONTIER Act on powerful AI systems, her CLAIM Act on liability, and more investment in cyber defence.^[47]

Posted 18:18 UTC, 21 Oct · 45.1K views · View on X

US National Security Agency

NSA Cyber @NSACyber

Advised every organisation using PHP to prepare for the update and, if an immediate update was not feasible, to take the system offline until it could be fully mitigated. It said it would follow up with more specific guidance.^[45]

Posted 13:45 UTC, 21 Oct · 10.1M views · 9.5K reposts · 63K likes · View on X

UK National Cyber Security Centre

NCSC UK @NCSC

Encouraged UK organisations to prepare for immediate updating of systems using PHP and, where that was not feasible, to consider taking the system offline until it could be fully mitigated.^[46]

Posted 10:07 UTC, 21 Oct · 967.8K views · 889 reposts · 3.3K likes · View on X

Others spoke in statements and interviews. South Korea’s deputy prime minister and science minister, Bae Kyung-hoon, said an extremely urgent response was needed because exploit code was already public, and called for automated measures such as blocking vulnerable internet-facing assets and adding firewall rules.^[40] Scotland Secretary Douglas Alexander told Times Radio he had no indication of a breach of Budget security after the Office for Budget Responsibility took its website down.^[41] The FBI’s cyber division told operators to watch for PHP processes unexpectedly launching command shells or downloading files.^[38]

Technology leaders

President and co-founder, OpenAI

Greg Brockman @gdb

Wrote that OpenAI led a coalition for two months to mitigate what he called one of the most severe open-source bugs in recent memory, found with its models under Patch the Planet, and that the bug had sat in PHP for 14 years. He said the end of the disclosure “didn’t go as planned” after the leak, and argued defenders will need new approaches, possibly including authorised defenders scanning for vulnerable hosts and, in extreme cases, patching them remotely.^[48]

Posted 14:58 UTC, 21 Oct · 308.3K views · 3.1K likes (article) · View on X

Co-founder and CEO, Cloudflare

Matthew Prince @eastdakota

Gave Cloudflare’s numbers: thousands of exploit attempts in the ten hours before the announcement, tens of thousands within 45 minutes after it, hundreds of thousands within two hours, and millions by the time of his post.^[49]

Posted 01:25 UTC, 22 Oct · 1.1M views · 2.1K reposts · 13K likes · View on X

CTO, Cloudflare

Dane Knecht @dok2001

Said Cloudflare’s rules went live at 03:02 UTC, that the early leak meant attackers were already mutating payloads against them, and that because the flaw is in the runtime, updating plugins will not fix it: “Patch PHP.”^[50]

Posted 14:09 UTC, 21 Oct · 305.3K views · 316 reposts · 1.6K likes · View on X

Two voices came through coverage rather than posts. Chainguard’s chief executive, Dan Lorenc, defended the early image release in interviews and on LinkedIn, and Patchstack’s chief executive, Oliver Sild, said on X that active exploitation attempts had been confirmed by Cloudflare and by several of its hosting partners.^[43][25]

Screenshots of public posts are reproduced for reporting and remain the property of their authors; each links to the original.

Section 14Myths and Facts

Section 15Mitigation: What Works, What Does Not

PHP’s position is explicit: updating is the only complete fix, and no configuration change makes an installation safe.^[1][2][6] The matrix below shows what each interim measure addresses. “Blocks” means it removes a confirmed path; “Partial” means it reduces exposure without closing the class; “No” means it does not help or makes things worse.

Reference configuration

These are the interim settings PHP and the vendors describe, written out so they can be reviewed. They reduce exposure; they do not replace the patch. Restart every worker after any change, and confirm the value through a request served by that SAPI, not through the command-line binary.^[2][5][6]

; Interim only. Patching is the fix. Restart ALL workers afterwards.
session.upload_progress.enabled = 0
; PHP 8.5 only: removes the confirmed fatal-backtrace producer
fatal_error_backtraces = 0

; PHP-FPM pool file
php_admin_value[session.upload_progress.enabled] = 0
; CVE-2026-109618 interim: removes the predictable limit, but raises denial-of-service risk.
; Monitor memory, and restore a finite limit AFTER the patch is verified.
php_admin_value[memory_limit] = -1

# Apache httpd with mod_php
php_admin_value session.upload_progress.enabled 0
php_admin_value memory_limit -1

# nginx (http context)
map $content_type $block_multipart { default 0; "~*^multipart/form-data" 1; }
# nginx (server or location context)
if ($block_multipart) { return 403; }

# Apache httpd with mod_rewrite
RewriteEngine On
RewriteCond %{HTTP:Content-Type} ^multipart/form-data [NC]
RewriteRule ^ - [F]

# Find every PHP runtime, not just the one on PATH (containers and panels need separate checks)
find / -xdev -type f \( -name 'php' -o -name 'php-cgi' -o -name 'php-fpm*' -o -name 'libphp*.so' \) 2>/dev/null
# Check each binary; distribution builds may keep an older number, so confirm with the vendor advisory
/path/to/php -v
# Show the parsed FPM configuration, including admin values per pool
php-fpm -tt 2>&1 | grep -E 'upload_progress|memory_limit'

After patching

Qualys and Tenable give essentially the same verification routine. Find every installation, including parallel branches, containers, hosting-panel packages and appliance-bundled PHP. Update the right package, binary or image and compare the full package version with the vendor advisory. Restart or redeploy workers and confirm they run the patched runtime. Then, only after verification, restore a finite memory_limit, review upload restrictions and worker recycling, and test behaviour under memory pressure, because the patched runtime can stop a worker at once at its hard threshold.^[9][7]

Section 16Detection and Hunting

The first indicators were published on 21 and 22 October, and most come from honeypots rather than victims. Amazon advises starting any investigation from 17 October, the earliest sighting.^[38] The harder problem is visibility: CrowdStrike says exploitation leaves almost nothing to see, with stable workers, HTTP 200 responses and clean application logs, and a single memory-limit fatal in the error log that is routinely dismissed as noise.^[38] The FBI’s own post tells operators to watch for PHP processes unexpectedly launching command shells or downloading files.^[38]

Single honeypot sightings are leads, not proof of compromise, and several of these addresses belong to anonymisation networks.

Unusually large or malformed PHPSESSID values, high field counts, repeated session parameters and memory-exhaustion errors or worker crashes are the strongest PHP2Shell-specific hints.^[4][11] For the second half, Huntress recommends alerting when PHP worker processes (php-fpm, php-cgi, httpd, apache2) spawn shells, interpreters or download tools, or run reconnaissance such as whoami, id and uname -a.^[8] At the network layer, Zafran’s signature keys on a body carrying both PHPSESSID and PHP_SESSION_UPLOAD_PROGRESS, a live blog reports Zeek and Suricata detections from Corelight and multipart boundary strings that reference the CVEs, and CERT-EU points to an NCSC-NL repository of software that embeds PHP. Treat the last two as pointers to check, not as verified signatures.^[35][34][29]

Starting points for hunting

Starting queries derived from the signals above. They are untested against real exploit traffic, so tune thresholds and expect false positives.

# 1. Memory-exhaustion fatals in PHP, web server or FPM logs since 17 Oct
grep -E "Allowed memory size of [0-9]+ bytes exhausted|Out of memory" /var/log/php*/*.log /var/log/apache2/error.log /var/log/nginx/error.log

# 2. Sources that cause bursts of HTTP 500 on POST in a combined-format access log (tune the threshold)
awk '$6=="\"POST" && $9==500 {c[$1]++} END {for (i in c) if (c[i] > 20) print c[i], i}' /var/log/nginx/access.log | sort -rn

title: PHP or web server worker spawning shell or download tool
status: experimental
description: Generic post-exploitation lineage for PHP code execution on Linux. Baseline legitimate shell-outs first.
logsource:
  category: process_creation
  product: linux
detection:
  parent_php:
    ParentImage|contains:
      - php-fpm
      - php-cgi
  parent_web:
    ParentImage|endswith:
      - /httpd
      - /apache2
  child:
    Image|endswith:
      - /sh
      - /bash
      - /dash
      - /curl
      - /wget
      - /nc
      - /python3
      - /perl
  condition: (parent_php or parent_web) and child
falsepositives:
  - Applications that legitimately shell out (image, PDF or mail tools)
level: high

Who can already see this for you

Section 17Patching by Platform

Section 18The GRC View: From Technical Event to Decision and Record

Control mapping (ISO/IEC 27001:2022, Annex A)

Clocks that may start

A register entry you can adapt

Section 19MITRE ATT&CK Mapping

Section 20Strategic Recommendations

• 01Inventory every PHP runtime, including containers, hosting-panel packages, appliances and Windows software that bundles php.exe or php-cgi.exe.^[9][8]
• 02Patch internet-facing mod_php first, then FPM and the rest. Where you cannot patch, isolate, take offline, or run read-only or GET-only.^[1][5][13]
• 03Apply admin-level interim settings (upload progress off, 8.5 backtraces off) and restart all workers, knowing they are partial.^[2][6]
• 04Block multipart at the edge where the application does not need uploads.^[5][6]
• 05Preserve web and PHP logs before you change anything if you suspect compromise, then isolate the server.^[8]

• 06Verify, do not assume: confirm the binary serving requests is patched, that workers restarted, and that no setting reinstates an old limit. Then restore a finite memory_limit and test behaviour under memory pressure.^[9]
• 07Hunt back to 17 October: memory-exhaustion fatals, bursts of 500s on multipart POSTs, odd PHPSESSID values, and web workers spawning shells.^[4][8][11]
• 08Consider rotating high-value secrets held by internet-facing PHP workers that were unpatched during the exposure window, because a memory-disclosure probe may leave no trace.
• 09Ask suppliers in writing for patch status on hosting, CMS, panel and appliance products.^[8]

• 10Retire or contain end-of-life PHP (5.4 to 7.3 now, 7.4 to 8.1 soon). Source backports are a bridge, not a destination.^[7]
• 11Make PHP a first-class asset class in vulnerability management, with the SAPI and the owner recorded.
• 12Write a “leak before patch” playbook: who can authorise taking a site offline, who files notices, how fast.

• 13Reduce the attack surface: disable session upload progress if unused (PHP recommends it even after patching), apply least privilege to worker accounts, filter egress from the web tier.^[2][11]
• 14Prefer immutable, rebuildable images so “patch” means “redeploy”, and keep a tested path for emergency base-image updates.
• 15Add a virtual-patching process for WAF or CDN rules, with an owner who checks the rules are blocking, not only logging.

Section 21Outlook

• Confirmed compromises and a catalogue entry. Amazon says the flaws are being broadly exploited and Cloudflare counts millions of attempts, but no successful compromise had been publicly confirmed at the time of writing. Reports said neither CVE was in CISA’s Known Exploited Vulnerabilities catalogue on 21 October; an entry would signal confirmed exploitation.
• Cheap automation against mod_php and multipart. Because the entry path is one well-defined request type, expect scanners to key on it and on the session upload-progress route.
• Follow-up releases. The change to out-of-memory handling is deep; expect regressions to surface, and expect variant hunting in the “object and extension state” family PHP lists but has not confirmed.^[1][2]
• Vendor advisories from CMS, framework and hosting-panel projects. Hardening or detection releases from WordPress, Drupal, Joomla, Magento, cPanel and Plesk are likely.
• The long tail. Estates on 5.4 to 7.3 will stay exposed; the quality of third-party backports will matter.^[7][19]
• Disclosure practice. PHP is moving to majority decisions and has an Ecosystem Security Team; watch whether distributors and the Foundation agree rules for early releases after the Chainguard dispute.^[28][31]
• AI-assisted variant analysis of other mature C and C++ runtimes. The same method should work elsewhere.

Section 22Sources 58

Official statements and advisories7

• [1]PHP — GHSA-w8hw-w9fx-j79w: CVE-2026-109618, “RCE via OOM corruption”
• [2]PHP — GHSA-6wmf-4rv5-p3rp: CVE-2026-109619, “RCE via stale global state”
• [26]php.net — Security advisory: critical remote code execution vulnerabilities, update now (21 Oct 2026)
• [27]php.net — Upcoming critical PHP security release (20 Oct 2026 pre-announcement)
• [28]PHP Foundation — Today’s PHP security release, and how we’re strengthening PHP security
• [29]CERT-EU — Security advisory 2026-018: critical vulnerabilities in PHP
• [37]CISA — Critical vulnerabilities in PHP require immediate patching (21 Oct 2026)

Researcher write-ups3

• [3]Calif — php2shell: a tale of two PHP vulnerabilities
• [4]Wiz Research — PHP2Shell: AI uncovers critical RCE in PHP
• [5]Sansec — PHP2Shell: Critical PHP RCE (CVE-2026-109618, CVE-2026-109619)

Vendor analysis & response guidance14

• [6]Rapid7 — CVE-2026-109618 and CVE-2026-109619: unauthenticated RCE in PHP
• [7]Tenable — php2shell: frequently asked questions about critical PHP RCE
• [8]Huntress — Rapid response: php2shell, leaked critical PHP vulnerabilities
• [9]Qualys — PHP announces critical security release for two vulnerabilities
• [10]Google Cloud — Responding to core PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619
• [11]Imperva — PHP2Shell: when PHP runs out of memory at the wrong moment
• [12]watchTowr — PHP remote code execution FAQ: CVE-2026-109618
• [23]Upwind — Initial assessment: PHP2Shell, two critical unpatched PHP RCEs
• [24]Cloudflare — Cloudflare deploys protections against the php2shell vulnerability
• [25]Patchstack — Major security alert: PHP vulnerable to critical RCE, attacks ongoing
• [30]AlmaLinux — php2shell: patched PHP packages released
• [34]Precursor Security — Live blog: PHP2Shell critical PHP RCE vulnerabilities
• [35]Zafran — PHP2Shell: everything you need to know about the two critical PHP vulnerabilities
• [39]OpenAI — Patch the Planet: global response coordination as agents uncover critical vulnerabilities

Press & official-response coverage19

• [13]Help Net Security — PHP2Shell: critical PHP vulnerabilities patched, update now
• [14]SecurityWeek — PHP2Shell patches land as first exploitation attempts hit sensors
• [15]Infosecurity Magazine — Critical PHP vulnerabilities leaked ahead of scheduled security patch
• [16]Techzine — PHP shuts the internet: why PHP2Shell affects every company
• [17]Reuters factbox (via Global Banking & Finance) — websites taken offline over PHP risks
• [18]Wikipedia — PHP2Shell
• [19]Hacker News — discussion thread “PHP2Shell: AI uncovers critical RCE in PHP”
• [20]Computer Weekly — What to do as critical PHP flaws put millions of websites at risk
• [21]Newsweek — PHP vulnerability: list of websites powered by PHP as hacker threat prompts scramble
• [22]The National — PHP vulnerability: websites go offline amid critical security update
• [31]Socket — PHP Foundation says Chainguard broke security embargo ahead of emergency patches
• [32]The Record — PHP says AI review of critical bugs first sparked alarm in August, but signs surfaced in 2024
• [33]The Next Web — PHP knew about one of the flaws in 2024 but could not agree a fix
• [36]php2shell.uk — PHP2Shell on shared and managed hosting
• [38]The Hacker News — Someone tried to exploit PHP2Shell 4 days before the vulnerabilities were publicly disclosed
• [40]The Korea Times — PHP security flaws alarm Korean government, companies
• [41]PA Media (Beccles & Bungay Journal) — No breach of Budget security after critical flaw found in PHP, minister says
• [42]zephel01 — What Japan has shut down and how it is recovering from the PHP vulnerability, as of noon on 22 October
• [43]Techzine — PHP accuses Chainguard in PHP2Shell

Posts on X15

• [44]Sanae Takaichi (@takaichi_sanae), Prime Minister of Japan — 21 Oct 2026
• [45]NSA Cyber (@NSACyber) — 21 Oct 2026
• [46]NCSC UK (@NCSC) — 21 Oct 2026
• [47]Lori Trahan (@RepLoriTrahan), US Representative — 21 Oct 2026
• [48]Greg Brockman (@gdb), OpenAI — “Towards securing the internet”, 21 Oct 2026
• [49]Matthew Prince (@eastdakota), Cloudflare — 22 Oct 2026
• [50]Dane Knecht (@dok2001), Cloudflare — 21 Oct 2026
• [51]Evan Solomon (@EvanLSolomon), Canada — 21 Oct 2026
• [52]Felipe Daragon (@FelipeDaragon) — post claiming the patched release was still vulnerable, later corrected
• [53]LCFR (@lcfr_hax) — announcement post with a WordPress exploit demonstration, 21 Oct 2026
• [54]Calif (@calif_io) — “php2shell: a tale of two PHP remote vulnerabilities”, 21 Oct 2026
• [55]sagitz (@sagitz_), Wiz — “Today we disclose PHP2Shell”, 21 Oct 2026
• [56]Wiz (@wiz_io) — announcement of PHP2Shell, 21 Oct 2026
• [57]LCFR (@lcfr_hax) — hash post, 5 Aug 2026
• [58]Rob Jetten (@MinPres), Prime Minister of the Netherlands — 21 Oct 2026