PHP2Shell: the critical PHP vulnerabilities, and who had shipped a fix
In October 2026 two flaws in the PHP engine — nicknamed PHP2Shell — could let an unauthenticated attacker run code on a vulnerable web server, and led governments around the world to take services offline as a precaution. This is a plain-English reference to what the flaws are and how the incident unfolded, built around an original census of when a fix reached each way you actually install PHP.
Updated 28 October 2026 · 35 install-channel families (92 release lines) tracked to primary sources, read on 27 October 2026 · method and dataset below
What this page is, and what it is not
Everything on this page is dated to 27 October 2026. It is a fast-moving incident; figures and fix states are a snapshot, not a live feed.
This is a count and a chronology, dated 27 October 2026. It is not a live exploitation feed, and it is not security advice for your specific estate — if you run PHP, patch and restart now, then check for compromise.
On exploitation we follow the evidence carefully: working exploits exist and the flaw is on CISA's exploited-vulnerabilities list, but several 'successful compromise' claims were retracted and no widespread real-world compromise had been publicly evidenced by 27 October. We do not overstate it in either direction.
If you just need the action: update PHP to PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12 (or your platform’s equivalent), restart every worker, then check for compromise. The how-to-fix section has the detail, including the mitigations if you can’t patch yet.
What PHP2Shell is
A failed memory allocation during request start-up leaves half-built internal data that PHP's clean-up code then trusts.
A worker keeps global state that points into one request's memory; a later request on the same worker reads it after it has been freed.
Both flaws carry PHP's own authoritative CVSS v4.0 base score of 9.2. Three other numbers are in circulation: the US National Vulnerability Database scores them 9.8 and 8.1 under the older CVSS v3.1 (it rates the second lower because it judges the attack more complex); and a figure of 10.0 circulated before release, which the PHP Foundation explicitly disowned — "the actual score is 9.2".
How the two flaws work
Scroll the chart sideways to see all of it →
CVE-2026-109618 · RCE via OOM corruption
PHP gives every request a memory budget (memory_limit), and historically used a C longjmp() to bail out when an allocation would exceed it. During request start-up, some internal structures are briefly reachable before they are fully built; if an allocation fails at that exact moment, PHP leaves that memory in an invalid state, and the request-cleanup code runs anyway and acts on it. An attacker reaches the out-of-memory moment through multipart form parsing — a request with no usable declared length slips past the initial size check, and empty file fields and deeply nested field names build large internal arrays while the upload on the wire stays small.
Worst case: Apache mod_php, which always runs request cleanup even when start-up failed and before any of the site's own code executes — so even a one-line 'Hello World' page is exposed.
PHP confirmed full unauthenticated remote code execution against mod_php with default settings. PHP-FPM is rated susceptible by code analysis, but no complete FPM exploit was demonstrated for this bug.
CVE-2026-109619 · RCE via stale global state
A PHP worker process serves many requests in turn and holds global state — error, session and extension data — that temporarily points into the current request's memory. That state must be wiped before the request's memory is freed, but a fatal error (including one caused by running out of memory) can abandon the matching reset, or a late diagnostic can refill the state after it was cleared. A later request on the same worker then reads or acts on freed memory. Exploitation needs a 'producer' request that leaves the dangling pointer and a 'consumer' operation in a later request that touches it before normal initialisation resets it.
Worst case: On PHP 8.5 the strongest demonstrated case is the fatal_error_backtraces global, whose reset is always missed on shutdown; this is the basis of the confirmed mod_php RCE. Session upload progress — enabled by default, needing no session_start() call — is the other confirmed path.
PHP confirmed unauthenticated heap use-after-free, memory disclosure and remote code execution. Unlike the OOM bug, this one was also demonstrated on PHP-FPM, through application fatal-error paths.
Who had shipped a fix, and when
Scroll the chart sideways to see all of it →
Counts release lines whose fix we could date, relative to the 21 Oct 2026 upstream release. Reference point, embargo breaks and the full 92-row dataset are in the download below.
Scroll the chart sideways to see all of it →
Four lines carry only a vendor statement or a note about an unrelated rebuild, with no fix verdict of their own.
Two honest caveats. Several of the earliest timestamps are file or build times, not the moment users could install — so “11 before the release” includes distributions that merely staged files early. The earliest fix appeared on the Wolfi/Chainguard channel: the Wolfi commit carrying it was merged at 03:36 UTC on 21 October, more than ten hours before the coordinated 14:00 UTC release, and Chainguard published patched container images at 07:41 UTC — the publication the PHP Foundation records as an embargo break.
| Channel | Fixed version | When | Status | Note |
|---|---|---|---|---|
| PHP upstream (php.net) 8.2 / 8.3 / 8.4 / 8.5 | 8.2.35, 8.3.36, 8.4.27, 8.5.12 | 21 Oct, 14:00 UTC | Fixed | the reference point; EOL 7.4/8.0/8.1 get source-only backports |
| Chainguard / Wolfi php-8.2 … php-8.5 | patched rebuilds of the prior versions | 21 Oct, 03:36 UTC | Fixed | the Wolfi commit carrying the private patch was merged ~10 h early; the patched images followed at 07:41 UTC (the embargo break) |
| windows.php.net 8.2 / 8.3 / 8.4 / 8.5 zips | 8.2.35 … 8.5.12 | 21 Oct, ~13:47 UTC | Fixed | directory timestamp; the 26 Oct '-1' rebuilds are a separate Brotli fix, not PHP2Shell |
| Debian 13 trixie — php8.4 | 8.4.27-1~deb13u1 | 21 Oct, 13:45 UTC | Fixed | DSA-6574-1; LTS/ELTS branches followed via Freexian |
| Ubuntu 24.04 / 26.04 LTS | 8.3.6-…, 8.5.4-… | 21 Oct, 13:56 UTC | Fixed | USN-8948-1; 7.x on older LTS via Ubuntu Pro/ESM |
| Ondřej Surý (ppa:ondrej/php, deb.sury.org) 7.4 … 8.5 | 8.5.12-1 … plus 7.4/8.0/8.1 backports | 21 Oct, 14:45 UTC | Fixed | shipped fixes for EOL branches too |
| Remi RPM repository EL 8/9/10 + Fedora | 8.2.35 … 8.5.12 (+ 7.4/8.0/8.1) | 21 Oct (file 13:49 UTC) | Fixed | file time; EOL branches labelled a 'mitigation fix' |
| Docker Hub official 'php' image 8.2 … 8.5 (all variants) | php:8.5.12 … 8.2.35 | 21 Oct, ~16:52 UTC | Fixed | the 8.1 / 8.0 / 7.4 tags are EOL and were not rebuilt |
| Alpine v3.24 — php83/84/85 | 8.3.36-r0 … 8.5.12-r0 | 21 Oct, 16:29 UTC | Fixed | older Alpine branches landed on 22 Oct |
| Homebrew (homebrew-core) php, php@8.2 … @8.4 | 8.5.12, 8.4.27, 8.3.36, 8.2.35 | 21 Oct, by 17:28 UTC | Fixed | php@8.1 is deprecated and was not updated |
| Red Hat Enterprise Linux RHEL 9 — php default (8.0) | php-8.0.30-8.el9_8.1 | 21 Oct, 20:06 UTC | Fixed | RHEL 8/10 main streams same day |
| cPanel EasyApache 4 ea-php82 … ea-php85 | 8.2.35 … 8.5.12 | 21 Oct | Fixed | ea-php74/80/81 got backported fixes |
| Plesk PHP handlers 8.2 … 8.5 | 8.2.35 … 8.5.12 | 21 Oct | Fixed | 7.4/8.0/8.1 backported on Linux |
| CloudLinux ea-php for cPanel | ea-php52 … ea-php85 | 21 Oct, 21:45 UTC | Fixed | alt-php and native PHP followed on 22 Oct; CloudLinux 6 still unconfirmed |
| Rocky Linux 9 — php / 8.2 / 8.3 | rebuilds of the RHSAs | 22 Oct, 00:04 UTC | Fixed | — |
| AlmaLinux 8 / 9 / 10 | rebuilds + own 7.2/7.3/8.0/8.1 fixes | 22 Oct, 13:25 UTC | Fixed | shipped EOL-stream fixes beyond RHEL on 23 Oct |
| Amazon Linux 2023 php8.2 … php8.5 | 8.2.35 … 8.5.12 | 22 Oct | Fixed | AL2023 php8.1 is marked 'No Fix Planned' |
| Red Hat Enterprise Linux EUS / AUS / TUS / E4S | module rebuilds | 23 Oct | Fixed | extended-support releases |
| Red Hat Enterprise Linux RHEL 7 ELS — php 5.4 | php-5.4.16-48.el7_9.1 | 23 Oct, 13:54 UTC | Fixed | fixes CVE-2026-109619 only; RHEL 7 is not affected by 109618 |
| Red Hat Enterprise Linux RHEL 9.6 EUS — php:8.3 | php-8.3.19-… | 26 Oct, 20:43 UTC | Fixed | the slowest genuine fix we traced |
| Red Hat Enterprise Linux RHEL 9 — php:8.4 module | none — Red Hat marks it 'Affected' | — | Pending | no erratum as of 27 Oct |
| Alpine edge/testing — php82, php81 | not rebuilt (8.2.34-r0 / 8.1.34-r6) | — | Won't fix | stable Alpine branches did ship php82 8.2.35 |
| Amazon Linux AL2 core php; AL2023 php8.1 | none — 'No Fix Planned' | — | Won't fix | — |
| Azure App Service built-in PHP on Windows; Azure Stack Hub | none — built-in runtimes are EOL | — | Won't fix | Linux Latest/Standard channels were fixed on 21 Oct |
| AWS Lambda PHP | no managed PHP runtime | — | N/A | PHP on Lambda is customer-managed (custom runtime / container) |
Scroll the table sideways to see every column →
Scroll the chart sideways to see all of it →
The slowest genuine PHP2Shell fix we traced is Red Hat Enterprise Linux 9.6 EUS php:8.3 (RHSA-2026:89111), on 26 October at 20:43 UTC — five days after release. The complete 92-row dataset, with a source URL and quote for every line, is the download at the foot of this page.
Downloads: CSV · README and licence · JSON. Free to reuse under Creative Commons Attribution 4.0 (CC BY 4.0) with attribution to Servnet Research and a link to this page.
How the incident unfolded
Who found it, and why it went unfixed
- The security firm Calif (researcher Ryan Austin) reported the first bug to the PHP project on 11 August 2026, having found it in early August during OpenAI's 'Patch the Planet' programme, using GPT-5.6 Sol; Wiz Research independently found and reported both flaws, crediting Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol.
- The PHP Foundation says a core developer first saw 'the first signs of the OOM problem' during a 2024 security audit (funded by Germany's Sovereign Tech Agency, run through OSTIF and carried out by Quarkslab), but a fix stalled — the Foundation calls the delay 'a structural failure, caused by both the security team's decision process and its lack of resources'.
- The PHP Foundation maintains the language with around 13 full- and part-time engineers and relies on donations — a point several commentators contrasted with the scale of AI-research funding.
- The disclosure did not go to plan: the CVE identifiers (and a wrong 10.0 score) leaked on 20 October, so PHP pulled the release forward a day to 21 October; Calif briefly published a proof-of-concept video; and Chainguard shipped patched images before the embargo lifted.
- 2024Background
A PHP core developer sees 'the first signs' of the OOM bug during the Quarkslab security audit. A fix is not agreed, and the issue is left open.
- 30 Jul – 24 Aug 2026Background
Calif and, separately, Wiz discover remote-code-execution paths in the PHP engine using AI tooling, and report them to the PHP security team.
- 20 Oct, ~15:00 UTCDisclosure
The two CVE IDs leak on Hacker News and social media, with a wrong release time and a wrong CVSS 10.0. PHP moves the release forward from 22 to 21 October.
- 20 Oct, 19:33 UTCVendor
PHP publishes an advance notice: a critical release at 14:00 UTC the next day, both flaws rated CVSS v4.0 9.2.
- 21 Oct, 07:41 UTCPatch
Chainguard publishes patched container images more than six hours early (the underlying Wolfi commit had been merged at 03:36 UTC) — it is this publication the PHP Foundation records as an embargo break.
- 21 Oct, 13:34 UTCVendor
The GitHub security advisories go live, about 26 minutes before the planned release time.
- 21 Oct, 14:00 UTCPatch
PHP releases 8.2.35, 8.3.36, 8.4.27 and 8.5.12, plus source-only backports for end-of-life 7.4/8.0/8.1. Distributions and panels begin shipping fixes within minutes.
- 21 OctImpact
Governments start taking services offline as a precaution — the Netherlands (incl. DigiD), Finland, France's Interior Ministry, Czechia, Canada — and UK councils including Edinburgh, Bristol and Oxford. Wikimedia, 4chan and several Japanese services go dark; Reuters also reported the Internet Archive going dark, though whether that was linked to PHP2Shell is disputed. CISA says it has 'not observed exploitation'; the UK NCSC advises considering taking systems offline.
- 22 OctImpact
In the Lords, a UK minister reports 32 government services unavailable and four partly so (largely precautionary), 50,000 NCSC notifications sent, and 'no confirmed compromise' of UK public-sector systems. Sophos claims one successful exploitation, then retracts it the same day.
- 23 OctVendor
PHP discloses a third, lower-risk flaw, CVE-2026-115560 (session upload progress), with no out-of-band fix — only the configuration mitigation. Unit 42 reports an attack on a European government agency.
- 24 OctExploitation
Researcher Adel Karimi publishes honeypot evidence of confirmed remote code execution — on a deliberately favourable single-worker Apache setup running PHP 8.4.26, consistent with CVE-2026-109618 only.
- 25 OctExploitation
Unit 42 retracts its European-agency attribution: it cannot tie the initial access to the PHP2Shell CVEs.
- 26 OctExploitation
Shadowserver reports 'no confirmed exploitation' against its sensors. CISA adds both CVEs to its Known Exploited Vulnerabilities catalogue (federal deadline 29 Oct). Trail of Bits confirms working exploits against pre-patch PHP 8.2–8.5 — in the lab, not in the wild.
- 27 OctBackground
This snapshot. Working exploits exist and the flaw is actively targeted, but no widespread real-world compromise has been publicly evidenced.
Scroll the chart sideways to see all of it →
Is it actually being exploited?
- Working exploits demonstrably exist. Calif, Wiz and Trail of Bits have each built them against real applications in the lab; Adel Karimi caught genuine remote code execution on honeypots on 24 October — on a single-worker Apache setup he deliberately made favourable to the flaw, and matching CVE-2026-109618 only.
- The flaw is being targeted. Amazon saw a probe four days before disclosure (17 October); Cloudflare reported tens of thousands of attempts within 45 minutes of the announcement. CISA added both CVEs to its Known Exploited Vulnerabilities catalogue on 26 October, with a 29 October deadline for US federal agencies.
- But confirmed real-world compromise has been elusive. Sophos claimed a successful exploitation on 22 October and retracted it the same day; Unit 42 claimed a government-agency case on 23 October and retracted it on 25 October; Shadowserver reported 'no confirmed exploitation' on 26 October; and the UK government reported no confirmed compromise of its systems. Much of the early 'exploitation' traffic was scanning, fingerprinting and non-working — in one researcher's words, 'AI slop'.
- The honest reading for a buyer: do not wait for proof of a breach. Attempts began before the patch existed, a reliable public exploit now exists, and the gap between disclosure and weaponisation was measured in hours, not weeks.
Why the care? Separating a working proof-of-concept and scanning traffic from a confirmed break-in is exactly the judgement that detection & response and incident response teams make daily. Knowing a CVE’s exploited status is what turns a patch queue into a priority.
How exposed is the web?
Scroll the chart sideways to see all of it →
Each figure counts something different: instances, IP addresses, hosts, app installs or websites. They are shown side by side, not added up.
The UK picture
Two third-party trackers give a UK picture. We cite their published figures; we did not reproduce their datasets.
- Infrawatch counted roughly 153,945 active PHP services in the UK. On 27 October its live tracker put the UK patch rate at about 27% of eligible, version-visible hosts — up from 8.5% on 22 October, and behind the Netherlands (~50%), Germany (~37%) and France (~36%), but ahead of the United States (~20%).
- Shadowserver, which added an 'end-of-life PHP' tag rather than a CVE-specific one, counted roughly 21,100 UK IP addresses still running PHP older than 8.2.
UK patch-rate and exposure figures are from third-party trackers (Infrawatch, Shadowserver), cited as published statistics; we did not reproduce their datasets. Shadowserver’s dashboard is funded by the UK FCDO.
The ‘Steal My Bitcoin’ challenge
- A site, stealmybitcoin.com, ran an unpatched PHP 8.4.26 server and offered a Bitcoin bounty to anyone who could break in using the PHP2Shell flaws. The prize started at about $500 and grew through donations to roughly $2,021 (0.0251 BTC). The organisers' stated aim was to test whether the flaws — and the claim that AI makes them easy to exploit — were as dangerous as reported.
- It survived the first ~17 hours untouched, which some read as evidence the flaw was overblown. Security researchers pushed back hard: the server was serving a static HTML page, so it never exposed a page that actually ran the vulnerable code. One researcher called using a misconfigured challenge as proof of safety 'a very dangerous narrative'.
- Once the organisers added a normal PHP-executing page (reported around 25 October), the server fell within hours (accounts put it at under three to under four hours). A researcher using the handle KillaBoi logged the win about 19 hours into the challenge and published a write-up.
- Reports differ on the payout — some say the recovered key did not match the advertised prize address, others that the prize wallet was emptied — and the site now shows the challenge as won. Crucially, the exercise does not show that an autonomous AI carried out the attack, and a single anecdote is not a measure of how exploitable the flaw is across real-world configurations. What it does reinforce is the main lesson: once the vulnerable path is reachable, exploitation is fast.
This account is drawn from reporting by several security and technology outlets (26–27 October 2026); Servnet did not interact with the challenge in any way. Outlets differ on who ran the site and on the payout details, and those points are flagged above.
How to fix it
Fixed versions: PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12 (released 21 Oct 2026). PHP 8.1 and older are end of life and get no official release — only source-only backport branches for 7.4/8.0/8.1; use a vendor package (your distro, Ondřej Surý, Remi, a control panel) or upgrade.
Update, then restart every worker
Installing the package is not enough: a reload leaves already-running workers holding the vulnerable code in memory. Restart (not reload) PHP-FPM, Apache or your container after updating. Capture forensic evidence first if you suspect compromise — a restart erases it.
If you cannot patch immediately
Partial, path-specific mitigations only: for CVE-2026-109618, set and enforce memory_limit=-1 administratively (and never use RLIMIT_AS / RLIMIT_DATA, which make it worse); for CVE-2026-109619, set session.upload_progress.enabled=0, and on PHP 8.5 also fatal_error_backtraces=0. Restart every worker afterwards. A web application firewall can blunt known payloads but is a stopgap, not a fix. Where none of this is feasible in time, several national cyber agencies advised considering taking the system offline until it is patched.
Mind the known rough edges
8.4.27 and 8.5.12 shipped with a SimpleXML garbage-collection regression (unrelated to the security fix) that can crash some applications; a source fix exists but, as of 27 October, had not yet shipped in a release. On Windows, the 26 October '-1' rebuilds fix a separate Brotli bug (CVE-2026-111497), not PHP2Shell — the PHP version is unchanged. And a third, lower-risk flaw, CVE-2026-115560 (session upload progress), has no fix yet; php.net advises session.upload_progress.enabled=0 until the next regular release, so every 'patched' build is still subject to it.
This episode is a stress test of how fast an organisation moves from disclosure to a deployed, verified fix. If PHP2Shell left you scrambling, the structural answers are patch management, vulnerability management, and segmentation on zero-trust lines so one unpatched app server can’t become a whole-network incident. Legacy stacks that can’t move quickly need compensating controls for end-of-support systems.
How this was built
How these figures were produced
- The patch-availability census is our own measurement. We traced each PHP install channel — Linux distributions and their extended-support tiers, container images, third-party repositories, control panels and cloud platforms — to a primary source (a vendor security tracker, advisory, package index or git commit), and recorded the fixed version, the date the source shows and an exact quote. Each row is classified fixed / pending / won't-fix / not-applicable, or statement-only where the source gives no fix verdict of its own.
- The reference point is the upstream PHP release on 21 October 2026, 14:00 UTC. 'Days after' is measured from that date; where a source gives a time we note hours relative to 14:00 UTC.
- Several timestamps are file or build times, not publication times, and some sources give no timezone; both are noted per row in the dataset, and a file existing is not the same as users being able to install it.
- The technical description is taken from the two GitHub security advisories, php.net and the PHP Foundation; the chronology, exploitation evidence, government response and exposure figures from primary sources (CISA KEV, national cyber agencies, Hansard, vendor telemetry posts) wherever possible, with each claim attributed.
- Third-party figures we could not independently reproduce — the Infrawatch and Shadowserver UK numbers, the exposure counts — are presented as attributed statistics, not as our data. The exposure figures are deliberately not merged, because they measure different things.
| Source | What it gave |
|---|---|
| PHP security advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp | the flaws, CVSS, affected and fixed versions, mitigations |
| php.net news archive and the PHP Foundation blog | release, source backports, the disclosure story, the third flaw |
| CISA Known Exploited Vulnerabilities catalogue | KEV addition dates and the federal deadline (public domain, CC0) |
| Vendor security trackers, advisories and package indexes | the 92-row patch-availability dataset, each row sourced |
| UK Parliament (Hansard) | the UK government's own statement of services affected and notifications sent |
Scroll the table sideways to see every column →
Related on Servnet
Servnet Research publishes dated observations from public sources for information only. It is not legal, security, financial or investment advice, and data are provided without warranty. Spotted an error, or want something re-measured or reviewed? See our corrections and takedown policy.
Our news desk also covered the event as it broke: PHP2Shell: UK hosting patch alert and why UK patching lags the EU. · More Servnet research
About this study
- What it is: A plain-English reference to CVE-2026-109618 and CVE-2026-109619 (“PHP2Shell”), built around Servnet’s own census of when a fix reached 35 PHP install-channel families (92 release lines), compiled from primary sources on 27 October 2026.
- Licence and attribution: Servnet’s derived dataset and compilation are free to reuse under Creative Commons Attribution 4.0 (CC BY 4.0), crediting Servnet Research with a link to this page. Vendor advisories and third-party statistics remain their publishers’ own and are cited, not relicensed.
- Third-party names: PHP, the PHP Foundation, CISA, Red Hat, Debian, Ubuntu, Microsoft, Amazon, Google, Cloudflare and other organisation and product names are trade marks of their respective owners, used only to identify products and organisations. Servnet is not affiliated with, endorsed by or acting for them.
- Our interest: Servnet sells and maintains IT infrastructure and security services, including some that would help an organisation respond to an issue like this. This page reports what the sources show; it is a reference, not security advice for your specific systems, and nothing here is a recommendation to buy anything.
- Errors and takedown: tell us at webmaster@servnetuk.com and we will check it; see the corrections and takedown policy.
Talk to a UK specialist
Get expert advice or a no-obligation quote — servers, storage, networking, maintenance, finance and cloud. We reply the same working day.