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 Lee, developer · Some technical · from the same 70 claims, selected and ordered for one reader

Is my code the problem, what do I change, and how do I check the box I deployed to?

This briefing v7 written in site v0.17.0 on 24 October 2026 · history and changes, 6 earlier

The answer in thirty seconds

Your code is not the problem and cannot be the fix: the flaw is in the engine beneath it. ini_set, .user.ini and auto_prepend_file all run too late. Check the running version where the code runs, after the restart, and tell the platform owner today if your target is 8.1 or older.

Read the site as Lee →

Your code is not the problem and cannot be the fix. The flaw is in the C engine that runs it. What you can do is check the box you deploy to and avoid making the engine's job harder.

What to decide or do

Check the running version where the code runs: php -v inside the container or phpinfo() on the box, after the restart. The package list is not the answer.
Fixed: 8.5.12, 8.4.27, 8.3.36, 8.2.35. If your target is 8.1 or older there is no release; tell whoever owns the platform today.
Nothing in userland blocks the demonstrated paths: ini_set() runs too late, .user.ini runs too late, auto_prepend_file runs too late. The settings have to be in php.ini, the pool or the server config.
Fix attacker-reachable fatal errors and timeouts in your own code anyway: the advisory lists them as one of the paths for the stale-state bug.
After the patch, out-of-memory behaves differently: a delayed fatal at the next safe point instead of an abort, and a hard limit that ends the process. Code that caught the old behaviour in tests will see a change.

Your reading path

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

What this briefing covers

is my code the problem
what I can and cannot do in userland
how to check the box I deploy to

What you can skip

the agency comparison
the money

Words you will meet

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

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

The facts this rests on

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
In researchers' own tests, 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

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, and Notebookcheck and Nguoi Quan Sat repeat that account. No copy of the 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, and the named cases do not state php2shell as the cause. Authorities in Singapore and Luxembourg now ask operators to look for traces; the answer will come from those searches, if it comes.
Which sites were really taken offline, and why. The list now draws on more captured reports (Germany's hospitals and hosts, Morocco, Romania, Japan), but most are press accounts; few come from the organisations themselves (the Dutch government, Latvia's agency, Weird Gloop, the Charité's spokesman as quoted). A community tracker counts 51 listed and 50 back.
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. On 23 October PHP published an informational advisory for a separate flaw, CVE-2026-115560, in the session upload progress feature, reported by Cloudflare, SOCRadar and The Hacker News: it affects fully patched releases including 8.5.12, needs a rare session setting, will be fixed in the next regular release, and has session.upload_progress.enabled=0 as the mitigation; SOCRadar reports no exploitation and no severity score. PHP's advisory is not in the evidence vault, and whether this is the bug the Fediverse report described is not stated.

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 · Website owner · 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 · Communications team.