Global – October 27, 2026 -- Roughly 2,000,000 internet-facing PHP servers run versions affected by two critical remote code execution flaws, CVE-2026-109618 and CVE-2026-109619, and 99.99% of identifiable servers remain unpatched, according to Shodan data cited by OX Security.
The PHP core team issued an out-of-band security release fixing both flaws in versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Shodan counts only servers that expose their PHP version, so the real total is likely higher.
69% of exposed servers run versions that will never get an official fix
About 1.37 million servers, or 69%, run old PHP versions outside vendor support. Only 245 servers showed a patched version as of the Shodan snapshot. Affected code spans all versions supporting session.upload_progress, from PHP 5.4.0 up to the unpatched releases.
Out-of-memory aborts leave PHP engine state corrupted
Both flaws stem from how PHP handles memory exhaustion: a longjmp abort via zend_bailout() that skips cleanup inside engine code mid-operation. The vendor advisories split the issue into two independently exploitable defects:
- CVE-2026-109618: a use-after-free and memory-corruption flaw. The abort leaves request memory in an invalid state before full initialization, and request shutdown then reads or branches on it.
- CVE-2026-109619: a use-after-free flaw. Worker-retained session, error, object and extension state points into a prior request's freed memory and is accessed before the next request resets it.
Default-enabled upload-progress handler requires no authentication to reach
The exposed surface is session.upload_progress, which is enabled by default. A multipart POST carrying PHPSESSID and PHP_SESSION_UPLOAD_PROGRESS fields triggers a session callback before the request's script compiles, whether or not the page uses sessions. Upload part count, field and file name lengths, and the progress value all drive allocation size. Reaching the memory limit needs no authentication, application cooperation or unusual configuration, according to OX.
Single commit makes out-of-memory recoverable
The fix is commit 01a40e89fb, "Avoid state corruption via bailout," by Arnaud Le Blanc and co-authors. It closes GHSA-w8hw-w9fx-j79w (CVE-2026-109618) and GHSA-6wmf-4rv5-p3rp (CVE-2026-109619). It makes four changes:
- Fallible allocations that return NULL on exhaustion, plus a new
memory_hard_limit_percentsetting. - A multipart parser that checks for exhaustion.
- An upload-progress handler that no longer forces the session active and loads no class code while decoding a session.
- Proper resets of startup-accessed globals.
Patched 8.2.35 passes all 77 OOM tests; 8.2.34 fails 7
OX built debug PHP from source for 8.2.34 and 8.2.35 and ran the roughly 77 oom_* regression tests shipped with the fix. The patched build passed all of them, while 8.2.34 failed seven. A single unauthenticated multipart upload reached the out-of-memory window on the vulnerable build.
Fake PoCs and unverified patches circulated before the official release
OX reports that an early leak produced an information vacuum on X and LinkedIn, with half-tested mitigations, AI-hallucinated fixes and dubious detection scripts in circulation. It advises security teams to avoid unverified PoC or patch scripts. If vendor guidance is pending, it recommends isolating or taking exposed instances offline, restricting public access to unpatched instances, and checking php -v and phpinfo() for the web SAPI, which can differ from the CLI.