On October 21, 2026, the PHP Foundation shipped emergency security releases fixing two critical remote-code-execution vulnerabilities in the PHP engine itself. The flaws, tracked as CVE-2026-109618 and CVE-2026-109619, both carry a CVSS score of 9.2 and can be triggered by an unauthenticated attacker. The patched versions are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35, and the Foundation calls updating "the only safe choice."
The release set off an unusually public alarm. Japan's Prime Minister Sanae Takaichi posted directly to businesses on X, urging them to check whether their public sites run PHP and to be ready for the fix — or to take sites offline if patching fast was not possible. The NSA, the FBI's Cyber Division, the UK's NCSC, Australia's ASD, Canada's cyber centre, and the EU's CERT-EU all issued parallel warnings. Cloudflare reported seeing early attack traffic and pushed WAF mitigations to free and paid customers hours before disclosure.
The two flaws
Both bugs live in core parts of the PHP engine that nearly every request passes through: memory management and error handling.
CVE-2026-109618 triggers when an out-of-memory condition interrupts PHP while internal request data is only partially initialized. Cleanup code then treats the invalid data as valid, corrupting memory in a way researchers turned into full remote code execution — demonstrated with default settings on Apache's mod_php, before any application code even runs. A separate code path produced the same outcome on PHP-FPM setups.
CVE-2026-109619 stems from a fatal error landing at the wrong point, leaving the engine's internal state pointing at memory that belonged to a previous request. A subsequent request handled by the same worker could then reuse that freed memory — a classic use-after-free that researchers developed into working RCE against a real production application.
The project's advisory puts every PHP installation serving web requests at risk, including PHP-FPM, Apache with modphp, php-cgi, FrankenPHP, and LiteSpeed, with the highest risk on modphp.
How the bugs surfaced
The root cause was first flagged back in 2024, during PHP's first external security audit — funded by Germany's Sovereign Tech Agency and carried out by Quarkslab. A core developer spotted warning signs while patching something else, but nobody could turn it into an exploit then, and fixes stalled for months amid disagreement over backward compatibility and ecosystem costs.
Things moved in August 2026. Security firm Calif, auditing PHP under the Patch the Planet program, reported an unconditional RCE path on August 11. OpenAI reported the identical issue independently the same day, with Wiz and OpenAI contributing further attack vectors through September. PHP's advisory credits researchers from Calif, Wiz, and OpenAI together.
The leak that forced an early release
The coordinated disclosure was set for October 21 at 14:00 UTC, with a wider embargo lifting the next day. It broke early. On October 20, the two CVE identifiers began circulating on forums and social media — misquoted with an inflated CVSS score of 10.0, though without technical details. PHP moved the release up to meet the leak.
Hours later, Calif mistakenly published a demo video of its proof-of-concept working against real targets before taking it down; copies spread anyway. Container-image provider Chainguard then broke the embargo entirely, publishing patched images more than six hours early — handing anyone who diffed the binaries a working blueprint for the fix. A proof-of-concept exploit circulated online, and Cloudflare watched attackers mutate payloads to dodge its rules.
Attackers were already trying before the patch
Amazon Threat Intelligence went back through its MadPot decoy network and found a PHP2Shell exploitation attempt dated October 17 — four days before the patches existed and three days before the leak. It came from an IP on a commercial anonymization network, aimed at a honeypot. Amazon's chief information security officer, CJ Moses, writes that targeting a decoy from an anonymized address suggests a threat actor at work, then concedes the gap that matters: nobody knows how that actor learned about the flaw, and it is unclear whether the attempt would have succeeded against a real server.
The days before disclosure were not quiet either. Cloudflare, watchTowr, Hadrian, Previdian and Patchstack all logged unsuccessful exploitation attempts while the embargo still held. Amazon saw multiple proof-of-concept exploits circulating from about 02:00 UTC on October 21 — twelve hours before the release went public at 14:00 UTC — and attempts hit its sensors almost immediately after that. Amazon's verdict is that the flaws are now being broadly exploited in the wild. How many of those attacks worked was a question nobody had answered as of October 23, when Unit 42 published the first confirmed case.
Hold those two claims apart. PHP Foundation executive director Elizabeth Barron told The Verge that "to our knowledge, there has been no successful attempt at remote code execution" - a statement about what was known on October 21, not a finding about what happened. That reading held for two days: widespread attempts, no confirmed break-in. On October 23 Unit 42 supplied the missing half, set out under "What we know, and what is still unconfirmed" below. The narrower lesson still carries: an unauthenticated memory bug fired at millions of servers mostly produces crashes, and the ones that work tend not to announce themselves. The MadPot finding stands on its own too - the disclosure date is not the start of exploitation, so a patch deadline counted from the advisory already starts late.
One vendor's yes turned into a no within five hours, and that is the most instructive detail of the week. Sophos's Counter Threat Unit wrote on October 22 at 16:18 UTC that its threat hunters had identified multiple exploit attempts and one successful exploitation, with a payload written to /tmp/nfs and executed — a likely Mirai variant it calls Potassium. At 21:21 UTC it corrected the record: the telemetry showed “scanning and a small number of failed exploitation attempts”, its own countermeasures blocked the attempt, and “as of this update, there is no evidence of a successful compromise due to these vulnerabilities.” The same update concedes that Sophos's own adversary group has been trying to build a working exploit and finding it hard even with AI assistance. Dataminr's threat research team read the first day the same way: scanning and fingerprinting, with public proof-of-concept code attached, rather than break-ins.
Sansec's own write-up pulls the other way on how dangerous the public code is. Its researchers write on October 22 that the public proofs of concept do not work against a default PHP installation, that most of them need the target application to already have a local file inclusion bug, and that mass exploitation has been "less likely than we expected on release day". Both readings fit the same evidence: the internet is being sprayed with attempts, and turning one into reliable code execution still needs the right target and the right conditions on it.
What to do now
- Update immediately to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35, depending on your branch. The PHP team provided minimal source backports for 7.4, 8.0, and 8.1 for those building from source; users of the volunteer-run remi repository are urged to switch to distribution packages or build from source.
- Older branches get no official fix. PHP 8.1 and earlier are out of support — CERT-EU notes the flaws may reach back to PHP 5, so anything that old must be migrated, not patched.
- Harden and check exposure. Follow the PHP team's additional hardening steps and temporary mitigations, inventory every place PHP runs (including appliances and services that bundle it — the NCSC's Dutch counterpart publishes an inventory list of possibly affected products), and prioritize internet-facing systems.
- If you cannot patch fast, consider going offline. The NCSC, NSA, and FBI all give the same fallback: take the system offline until it can be mitigated, then check for compromise — look for PHP processes spawning unexpected command shells — before bringing it back.
Distribution fixes land, including for old releases
On October 22, Ubuntu published fixes for every supported release going back to 14.04: current branches (22.04 through 26.10) under standard support, and 14.04 through 20.04 — php5, 7.0, 7.2, and 7.4 — through Ubuntu Pro's Expanded Security Maintenance, which is free for up to five machines. Debian fixed trixie and bookworm the same week. This changes the calculus for anyone stuck on an end-of-life PHP branch on these distributions: patching the distro package, rather than migrating PHP branches under fire, is now the faster path. After upgrading, restart Apache, PHP-FPM, or any long-running PHP workers — the new binary only takes effect once old workers are gone.
One version-number trap to know: distro packages keep their own numbering, so PHP_VERSION on a fixed Ubuntu 24.04 box still reports something like 8.3.6 — check the package version (dpkg -l 'php*') or the changelog for the CVE numbers instead of grepping for the upstream release.
Who has shipped fixes, and who is still catching up
Upstream PHP only covers branches 8.2 through 8.5, so for everyone else the fix has to come from whoever ships their PHP. That picture is uneven and changing by the hour. What follows reflects October 22 reporting; check your own vendor before assuming you are covered.
- cPanel / WHM: EasyApache 4 had rebuilt ea-php packages within minutes of the advisory, according to server monitor mySites.guru — update through WHM or yum/dnf update 'ea-php*'. Switching PHP versions in MultiPHP Manager does not install the fix; the packages themselves must update.
- Plesk: says every PHP version it ships is affected and is rebuilding them all — check Tools & Settings, Updates.
- CloudLinux: patching every PHP version it ships, including backports for 7.4 through 8.1 that upstream no longer releases.
- AlmaLinux: backporting to its module streams and said its builds would ship ahead of Red Hat's; Red Hat had no fixed packages at the time of AlmaLinux's post. Red Hat rates the flaws Important (CVSS 3.1 8.1) against PHP's Critical (CVSS 4.0 9.2).
- Debian: trixie fixed (DSA-6574-1) and bookworm fixed (DLA-4848-1); sid was still unfixed when last checked. Ubuntu covered separately above.
- Third-party repositories lag: Ondrej Sury's PPA and Remi's repo had no fixed builds on release day — Remi's is not expected to get them — so users of those repos need distribution packages or a source build.
- If you are on shared or managed WordPress hosting, there is no button to press: the interpreter belongs to your host, not your WP admin. Updating WordPress does nothing for this flaw. Ask your provider exactly when patched packages land and for which branches — mySites.guru found only 0.08% of monitored live sites on a fixed PHP version on the afternoon of release day, and Wordfence warns automatic updates will not apply the fix.
PHP's own developers are blunt about workarounds: per one core developer, the only mitigation is patching or upgrading, and release managers add that ini settings will not save you. Treat the temporary hardening flags as exposure reduction while you wait for packages, not as a fix.
A third RCE, disclosed on October 23
Two days after the emergency releases, PHP published a short informational advisory for a third remote-code-execution path, now tracked as CVE-2026-115560 — and the October 21 updates do not fix it. Reaching it takes an unusual setup: an application configured with session.serialize_handler set to php_binary or php_serialize, then switched back to php at runtime with ini_set() before session_start(), with session upload progress still enabled. PHP calls that combination unlikely in practice, so it is not shipping an emergency patch; the fix and the full advisory arrive with the next regular bugfix release. The bridge it recommends is one line: set session.upload_progress.enabled=0 in php.ini, an FPM pool, or a .user.ini file, and restart every worker. That is the same setting PHP already listed as a mitigation for CVE-2026-109619, so anyone who applied it on October 21 and left it in place has nothing more to do. The directive is PHP_INI_PERDIR and cannot be changed at runtime with ini_set(), which is worth knowing before trusting a plugin that says it handled it. CERT-EU and Canada's cyber centre both updated their advisories on October 23 to carry the new CVE, and both say the same thing: an application that never changes the serialize handler at runtime is not exposed through this path.
What we know, and what is still unconfirmed
Widespread exploitation attempts, including before disclosure, are established by vendor telemetry and by Amazon's decoy network. A successful compromise is now established too: on October 23 Unit 42's updated threat brief described the case of a European government entity where attackers using an agentic AI platform reached password hashes and multi-factor authentication secrets within two hours of the initial exploitation, opened an NTLM-relay tunnel into Active Directory, and attempted Domain Admin privilege escalation. Unit 42 does not name the government or the country, and no second vendor has published a separate confirmed breach - SecurityWeek, Hunt.io, Wordfence and SOCRadar were all still reporting attempts only when they last checked on October 23. Neither of the two CVEs is in CISA's KEV catalog, which is built on evidence of exploitation rather than attempts; the catalog was last refreshed on October 23, 2026 and still held 1,756 entries when re-checked on October 24, with neither identifier in it - nor CVE-2026-115560. Indicators of compromise do now exist, of a narrow kind: Amazon published six source addresses, five of them seen on October 21, and warns that they are shared anonymization infrastructure - worth investigating, not worth blocking on their own. On the version question, Ubuntu and Debian have published fixes covering releases back to 14.04 and Debian oldstable respectively, narrowing the set of systems with genuinely no patch path. We will update this post as CISA and national CERTs publish more.
Last updated October 24, 2026: Unit 42 has now confirmed a successful compromise - a European government entity, documented in its October 23 threat-brief update - the KEV catalog was re-checked and still lists neither CVE, and PHP's third RCE advisory (CVE-2026-115560) from October 23 is carried above. We will revise this post as official advisories evolve.
No comments yet