PHP 8.5.12 and 8.4.27 Fix Two Leaked RCE Bugs: What to Do Now

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released October 21, 2026, fix two critical unauthenticated remote code execution bugs (CVSS v4.0 9.2) whose details leaked before the patch. PHP’s security advisory says every PHP installation serving web requests is at risk, with the highest risk on Apache mod_php, and that updating is the only complete fix. The release followed the project’s first-ever advance notice, issued a day early because a Hacker News post, a demo video and the CVE IDs CVE-2026-109618 and CVE-2026-109619 were already circulating. This post covers what the bugs are, how the leaks compare with the official advisories, who is most exposed, the official stopgaps, and how to check and update your PHP version.

TLDR

Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 now. CVE-2026-109618 lets an attacker push PHP into out-of-memory handling while request data is half-initialized, and CVE-2026-109619 lets stale state from one request be used after its memory is freed in a later request; both can lead to unauthenticated remote code execution. PHP calls the risk highest for mod_php, where a demonstrated exploit fires before any application code runs, and says its published config changes reduce exposure but do not make a server safe. PHP 8.1 and older get no release, only minimal source backports, so those sites need a vendor fix or an upgrade.

Thoughts

PHP has never done this before, and that tells you how bad the leak was. A search of every php.net news page from 2001 through 2026 for “advance notice” or “upcoming security release” turns up exactly one hit, this one. When DEVCORE reported the PHP-CGI argument injection bug (CVE-2024-4577) in May 2024, PHP shipped the fix in June with no warning at all, and that bug still ended up exploited within days and used by ransomware crews. This time the embargo was already broken, so PHP had two bad options: stay quiet while attackers worked from leaked hints, or warn everyone and pull the release forward a day. It picked the second, and the cost landed on the volunteers downstream. Remi’s RPM repo, which many RHEL-family servers rely on, did not ship updates on release day, and PHP’s own advisory told its users to switch to distribution packages or build from source. Coordinated disclosure only works while the secret holds, and once it fails, everyone, defenders included, is on a compressed clock.

The detail that should worry site owners most is where the bugs live. Both sit in PHP’s request handling, below the application: PHP parses multipart form bodies during request startup, and the advisory describes a demonstrated mod_php exploit where an unauthenticated request triggers the attack before any application code runs. It does not matter whether the site runs WordPress, Laravel, Magento or a hello-world script, and no security plugin ever sees the request. That is why a WordPress maintenance-mode plugin does nothing here, and why WordPress auto-updates, which never touch the PHP binary, will not save you either. Most site owners have spent a decade being told to keep plugins and themes updated, but this time the vulnerable code sits one layer below anything they manage.

For anyone on shared hosting, the honest answer to “how do I patch?” is that you cannot. Hosts like Hostinger let you pick a PHP branch (8.2 through 8.5) but not a point release; the host installs 8.4.27 when it gets around to it. So the practical moves are a fresh backup before the host touches PHP, a written question to support asking for the deploy ETA, and a one-line check once they say it is done: curl -sI https://yoursite.com | grep -i x-powered-by should show the new version number. If the site is not earning money hour to hour, taking it offline until that header changes is the safest option, and both CERT-EU and the UK NCSC suggest exactly that for unpatchable internet-facing systems. After patching, it is worth looking for signs of compromise from about October 20 onward: new admin users, unknown plugins, .php files inside the uploads folder, and unfamiliar cron jobs.

Comparing the leaks with the official advisories is a useful lesson in how much to trust pre-release chatter. The leaks got the CVE IDs, the fixed version numbers, the pre-authentication remote code execution and the 9.2 score right. They got the mechanism only partly right. Independent write-ups pinned everything on a use-after-free in session upload progress, and the widely shared fix was to turn that feature off. The advisories describe two broader classes of bug: out-of-memory handling that leaves request data invalid (CVE-2026-109618), and stale global state reused across requests (CVE-2026-109619). Disabling upload progress blocks only the confirmed session paths of the second one and does nothing for the first. Anyone who flipped that setting yesterday and stopped there is still exposed. The lesson is to wait for the advisory and leave the “proof of concept” code alone, since Tenable warned that unverified exploits are sometimes laced with malware.

Key Takeaways

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 were released on October 21, 2026 to fix CVE-2026-109618 and CVE-2026-109619, both rated CVSS v4.0 9.2 and both allowing unauthenticated remote code execution.
Every earlier release on those branches is vulnerable: anything below 8.5.12, 8.4.27, 8.3.36 or 8.2.35.
CVE-2026-109618 (RCE via OOM corruption): out-of-memory handling can interrupt PHP while request data is only partially initialized, and request cleanup then treats the invalid data as valid.
CVE-2026-109619 (RCE via stale global state): request-owned internal state can survive after its memory is freed, and a later request on the same worker can use it, a use-after-free.
PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed are all affected; PHP rates mod_php highest risk, with a demonstrated exploit that runs before any application code.
The advance notice existed because the bugs leaked. watchTowr said the original embargo was meant to end Thursday, October 22 at 11:00 AM ET, and a PHP core developer confirmed a leaked video drove the timing.
PHP 8.1 and older get no release, but PHP published minimal source backports for 7.4, 8.0 and 8.1; distributions and LTS vendors received the patches in advance.
Cloudflare’s CTO said early on October 21 that Cloudflare was “seeing early attacks emerging” and had pushed WAF rules to every plan, including free.
Sansec expected mass exploitation within 15 minutes of the release, because the patch diff shows attackers exactly where to look.
Setting session.upload_progress.enabled=0 only blocks the confirmed session paths of CVE-2026-109619 and does nothing for CVE-2026-109618.
PHP’s stopgaps for CVE-2026-109618 include memory_limit=-1 set where applications cannot override it, a low post_max_size, and request-size limits at the web server or proxy.
Shared hosting customers cannot patch PHP themselves. The host has to deploy the fixed build, so ask support directly for an ETA.
On Ubuntu and Red Hat, check the package version rather than php -v, because backports keep the old upstream version number.
Remi’s RPM repo did not ship updates on release day; PHP told its users to switch to distribution packages or build from source.

Detailed Summary

The Advance Notice

On Tuesday, October 20, 2026, the PHP security team posted an advance notice on php.net, and Jakub Zelenka sent it to the php.announce mailing list at 3:33 PM ET. The notice named a release time of 14:00 UTC on October 21, two critical vulnerabilities, and a CVSS v4.0 score of 9.2 for each. PHP said full details, affected versions and fixed versions would come with the release, and that it might ship earlier if details went public or exploitation appeared. It shipped on schedule with a security advisory and two GitHub advisories.

How the Embargo Leaked

Around 11:20 AM ET on October 20, a since-deleted Hacker News post claimed two critical PHP RCEs would be disclosed on October 22, naming both CVE IDs. Within hours, Kevin Beaumont wrote that someone had leaked the CVEs before the patch, and watchTowr said it could confirm the bugs were real and had reproduced CVE-2026-109618. Florian Roth said he had heard about a PHP RCE the week before and had already built a monitoring tool. Kirill Firsov later posted a three-minute “php2shell” demo video, credited by others to LCFR and Calif.io, and PHP’s announcement followed the same afternoon.

Affected and Fixed Versions

The fixed releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35, matching the numbers Beaumont and Tenable reported in advance. According to PHP’s supported versions page, 8.5 and 8.4 are in active support and 8.3 and 8.2 get security fixes only, and PHP notes that 8.2 reaches end of life on December 31, 2026. For 7.4, 8.0 and 8.1 there is no release, but the security team published minimal source backports for people who build from source or have no LTS vendor. Ondřej Surý’s Debian and Ubuntu repository said it would ship fixes for every PHP version it carries, and distros and commercial vendors such as TuxCare may backport too.

What the Two Vulnerabilities Are

CVE-2026-109618 abuses the way PHP exits on out-of-memory errors. Multipart parsing tricks (bodies without a usable content length, parts with huge numbers of headers, empty file fields with nested names) can drive a request out of memory at a moment when request memory is not yet valid, and shutdown then acts on it; Apache mod_php is especially exposed because it runs shutdown even when startup failed. CVE-2026-109619 is a use-after-free: worker-level state that points into one request’s memory is not reset, and an operation in the next request reads it before initialization replaces it. Both carry the vector AC:H/AT:P, meaning an attack needs specific conditions, which explains the 9.2 rather than a perfect score. The leaked write-ups that blamed session upload progress described one confirmed path for CVE-2026-109619, not the whole picture.

Exploitation and Proof-of-Concept Code

Cloudflare’s CTO Dane Knecht reported early attacks overnight but gave no numbers or success rates. Huntress and watchTowr had not observed exploitation as of October 20, and Aikido reported in-the-wild exploitation early on October 21. Several public repos and a “jackalsyn” tarball claimed to be exploits, but Ondřej Surý’s tracking thread warned the tarball was unvetted and at best crashed a worker. Sansec expected mass attacks within minutes of the release, since the patch diff itself shows where the bugs live.

Why the Advance Notice Was a First for PHP

PHP normally ships security fixes with a ChangeLog and GitHub advisories on release day, as it did with the September 24 batch. The 2024 PHP-CGI argument injection bug, CVE-2024-4577, got no advance notice, and neither did CVE-2019-11043 in PHP-FPM with nginx. Both are now on CISA’s Known Exploited Vulnerabilities list with known ransomware use. Other big projects, OpenSSL most famously, routinely pre-announce critical releases, but PHP had not until the leak forced it.

Who Is Most at Risk

PHP says every installation serving web requests is at risk, naming PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed, and rates mod_php highest. End-of-life PHP is especially exposed because there is no official release. Shared hosting is high risk because the customer cannot patch, and control panels or appliances that embed PHP (cPanel, Plesk, CyberPanel, CloudPanel, firewalls, NAS boxes, VPN portals) wait on vendor updates. Command-line-only PHP with no web exposure is low risk. Tenable cites estimates of 1.3 million to 1.9 million exposed hosts, and W3Techs puts PHP at 69.3% of websites whose server language is known.

Official Stopgaps If You Cannot Update Yet

PHP is explicit that only an update is a complete fix, and that its stopgaps reduce exposure without making a server safe. For CVE-2026-109618 it suggests memory_limit=-1 set where applications cannot override it (such as php_admin_value), a low post_max_size (8M without uploads, 32M with them), request limits at the web server or proxy, and container or cgroup memory limits rather than RLIMIT settings. For CVE-2026-109619 it suggests session.upload_progress.enabled=0 in php.ini or the pool config with every worker restarted, fatal_error_backtraces=0 on PHP 8.5, and fixing per-request settings and fatal errors an attacker can reach. Beyond that, taking the site offline, as CERT-EU and the UK NCSC recommend for unpatchable systems, or blocking multipart requests at the edge remain the strongest options.

How to Check and Update Your PHP Version

WordPress shows the PHP version under Tools, Site Health, Info, Server, and hosting panels usually list it on the PHP configuration page. On a server, php -v shows only the CLI, so also check php-fpm8.3 -v or the package version, since Ubuntu and Red Hat backports keep the old upstream number. Debian and Ubuntu users upgrade the php8.x packages and restart PHP-FPM or Apache, RHEL-family users run sudo dnf upgrade 'php*', and Docker users pull the new tag once it appears and rebuild. FrankenPHP needs a new FrankenPHP release, LiteSpeed needs the lsphpXY packages plus sudo pkill lsphp, and cPanel fixes arrive as EasyApache 4 ea-php packages. Source and Windows builds are on PHP’s downloads page, and Mattias Geniar’s patch guide has the full recipes.

Notable Quotes

“Somebody has leaked CVE-2026-109618 and CVE-2026-109619 in PHP before the patch is out.”
Kevin Beaumont, security researcher, on Mastodon the afternoon the leak surfaced

“We were all supposed to wait until Thursday at 11am ET… We can confirm that they’re real.”
watchTowr, on X, confirming the leaked bugs and the original embargo date

“All PHP users are encouraged to prepare now so they can upgrade as soon as the release is available.”
PHP security team, in the advance notice on php.net

“the only mitigation is patching / upgrading PHP. I sadly know too much.”
Gina Peter Banyard, PHP core developer, on Mastodon

“ini settings won’t save you”
Joe Ferguson, PHP 8.6 release manager, as quoted by Tenable

“There are no complete mitigations, updating is the only safe choice.”
PHP development team, in the 8.5.12, 8.4.27, 8.3.36 and 8.2.35 release announcements

Read PHP’s security advisory on php.net, and the GitHub advisories for CVE-2026-109618 and CVE-2026-109619 for the full technical details.