Research collected from outside sources and what this site derives from them; every fact links to a saved copy of its source Research or story?

Briefing for Casey, website owner · Plain English · from the same 70 claims, selected and ordered for one reader

My website runs on WordPress or similar: am I affected, and what do I ask my host?

This briefing v4 written in site v0.5.9 on 22 October 2026 · history and changes, 3 earlier

The answer in thirty seconds

If your website runs on WordPress, Drupal, Joomla or anything else written in PHP, it is in scope: the flaw is in PHP itself, underneath your site. Updating plugins does not fix it. If someone hosts the site for you, ask them in writing whether PHP has been updated to a fixed version and restarted. If you run the server yourself, update PHP today.

Read the site as Casey →

You do not need to understand the bug to deal with it. What you need is to know whose job the update is, and the exact question to ask. This page gives you both.

What to decide or do

Find out whether your site runs on PHP. WordPress, WooCommerce, Drupal, Joomla, Magento, PrestaShop, Moodle and most hosting control panels do. If you are not sure, ask whoever built the site.
Updating WordPress, plugins or themes does not fix this. The flaw is in PHP itself, one layer down. It has to be fixed on the server.
If someone hosts the site for you, send them this, in writing: Has PHP on the server running my site been updated to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your distribution's fixed package, and have the PHP processes been restarted since? If my site is on PHP 8.1 or older, what is your plan? Keep the reply.
If you run the server yourself, update PHP today and restart it. The step-by-step list has the temporary settings for a server you cannot update straight away.
If your site is on PHP 8.1 or older, there is no ready-made fix. Ask your developer or host about moving to a supported version now; it is overdue anyway.
Keep calm about being hacked. No organisation has confirmed a break-in as of the latest capture. If your host updated promptly, you are in the same position as almost everyone else.

Your reading path

About 14 minutes in all. Choose read as Casey and the bar under the menu keeps your place on every page.

What this briefing covers

am I affected
is it my job or my host's
exactly what to ask the host
whether updating WordPress plugins helps

What you can skip

the code
the disclosure politics
the agency comparison

Words you will meet

PHP Primary source CVSS Vulnerability GitHub advisory (GHSA)Remote code execution (RCE)mod_php Out of memory (OOM)longjmp CVE Exploit, exploitation Proof of concept (PoC)PHP-FPM SAPI

Each is underlined where it first appears; hover or tap for a one-line definition, or open the glossary.

The facts this rests on

Show the 33 claims behind this briefing, each with its status and sources

confirmed two or more primary sources agree, or the fact was counted from a captured file
reported one party says so, and it has not been contradicted
disputed the sources disagree, and both readings are shown
contradicted a primary source says otherwise
unverified even the reporting outlet could not check it
p/n primary sources among the n cited; a blocked capture is counted and marked

Claim	Who says it	Status	Fact-check	Primary	Sources
Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fact timeline →	PHP Group (CNA), GitHub advisories, php.net	confirmed	A6 Established	5/5	CVE record CVE record PHP PHP php.net
Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs fact timeline →	PHP security team (GHSA, oss-security), php.net	confirmed	A6 Established	3/3	PHP oss-security php.net
The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' fact timeline →	PHP security team	confirmed	A6 Established	3/3	PHP php.net php-src
Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe fact timeline →	php.net; PHP security team	confirmed	A6 Established	3/3	php.net oss-security PHP
Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity high Fastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. fact timeline →	Imperva; Fastly; the CVE record	confirmed	A3 Echoed opinion status overstated	3/3	Imperva Threat Research Fastly CVE record
Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed request The fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. fact timeline →	php/php-src fix commit; the GitHub advisories	confirmed	A6 Established	3/3	php/php-src, read from a clone PHP PHP
Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCS Two researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. fact timeline →	Calif; Wiz for WordPress and Drupal	reported	A2 Reported	2/2	Calif Wiz
None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200 The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. fact timeline →	rjmendez (detection author) citing VulnCheck; Huntress	reported	A1 Weak signal status overstated	1/2	rjmendez, GitHub Huntress
Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expected A position, from a vendor; consistent with the Fediverse report of a third bug. fact timeline →	Fastly	reported	A2 Reported opinion	1/2	Fastly oss-security
Remote code execution is confirmed on PHP-FPM GHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. fact timeline →	PHP Foundation blog; GHSA-6wmf for the session path	disputed	A6 Established	4/4	PHP Foundation PHP PHP oss-security
All PHP versions from 5 onwards are affected by at least one of the flaws The CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. fact timeline →	NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1)	disputed	A3 Echoed disputed	3/4	NCSC-NL Wiz on X CERT-FR oss-security
A web application firewall may provide some protection until systems are patched Swiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. fact timeline →	CISA	disputed	A6 Established	3/3	CISA BACS Cloudflare
The flaws are CVSS 10.0 The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. fact timeline →	social posts on 20 October, relayed by a vendor and a news site	contradicted	refuted contradicted	1/2	PHP Foundation Daubois
The 8.5.12 fix may be incomplete, or there is a third, different bug Per a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. fact timeline →	Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez	unverified	A1 Weak signal opinion disputed	0/1	oss-security
If an immediate update is not feasible, take the system offline until it can be fully mitigated X post 13:45:58Z 21 October (10.1 million views at capture) and the press release. fact timeline →	NSA Cybersecurity	confirmed	A6 Established	2/2	NSA Cyber on X NSA
Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline fact timeline →	CISA	confirmed	A6 Established	1/1	CISA
Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 October Every vendor says the same two things: it is a stopgap, and patch anyway. fact timeline →	the vendors	confirmed	A2 Reported status overstated	5/5	Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community
The risks require immediate patching across United States Government departments and agencies No CISA emergency directive was visible on the CISA home page at capture. fact timeline →	NSA	reported	A6 Established	1/2	NSA CISA
'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated' That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. fact timeline →	UK NCSC, as quoted by the BBC	disputed	A2 Reported disputed	2/3	BBC News NCSC UK CCCS
The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasible Australia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. fact timeline →	BBC	contradicted	A1 Weak signal	4/6	BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC
CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalog Catalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. fact timeline →	CISA	confirmed	A6 Established	3/3	CISA CISA CVE record
Amazon and Cloudflare saw sites being probed for the flaw Both companies have since said so themselves. fact timeline →	Alan Woodward, via the BBC; confirmed by both companies' own posts	confirmed	A5 Confirmed	2/3	BBC News Cloudflare Amazon
The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one day Counted from the captured catalog. fact timeline →	CISA KEV catalog; Akamai (2024)	confirmed	A2 Reported status overstated	3/3	CISA CVE record Akamai Security Research
There is no evidence yet that hackers have exploited the flaw fact timeline →	Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October	reported	A2 Reported disputed	0/1	BBC News
Reports of active exploitation exist The only agency saying so, and it does not say whose reports. fact timeline →	NCSC New Zealand	reported	A2 Reported disputed	1/1	NCSC New Zealand
An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild' Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. fact timeline →	Amazon (CJ Moses, AWS Security Blog)	reported	A2 Reported disputed	1/2	Amazon THN
Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloads Primary party, no volumes. fact timeline →	Cloudflare	reported	A2 Reported	1/1	Cloudflare
Automated exploitation attempts were seen in Latvia; none succeeded Primary source. fact timeline →	CERT.LV	reported	A2 Reported	1/1	CERT.LV
Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTC Primary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. fact timeline →	Matthew Prince, Cloudflare CEO, on X	reported	A2 Reported measures differently	1/1	Matthew Prince, Cloudflare CEO on…
No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoring A negative finding from a party that had the details under embargo. fact timeline →	Imperva Threat Research	reported	A2 Reported measures differently	1/1	Imperva Threat Research
No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress fact timeline →	Huntress	reported	A2 Reported disputed	1/1	Huntress
Criminals are using AI to 'vibe code' an attack method fact timeline →	unnamed researchers, via the BBC	unverified	A1 Weak signal opinion	0/1	BBC News
watchTowr sees active exploitation attempts and lists the flaws as exploited in the wild watchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. fact timeline →	watchTowr	unverified	A4 Corroborated superseded	2/2	watchTowr watchTowr

Every sentence above rests on these rows. They are folded away because they are written in the sources' own vocabulary; the glossary explains each term.

What is still open

Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.
Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.
Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.
Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.
Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.

The full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Data protection officer · Head of AppSec · Developer · Communications team.