PHP 8.5.12 and 8.4.27 fix two critical RCE flaws

PHP released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on October 21, 2026, to fix two critical flaws. Both can let an attacker run code on a web server without logging in. The PHP.net security advisory tells every PHP user to update immediately. It adds that no setting change fully protects a server, so installing the new release is the only safe choice.

PHP announced this out-of-cycle release a day earlier, after details of the bugs leaked ahead of schedule. We covered that advance notice this morning. Today's release answers the open questions: which versions are fixed, what the bugs do, and who is most exposed.

What the two PHP flaws do

Both bugs sit in the code that sets up and cleans up each web request. PHP rates each one 9.2 on CVSS v4.0, the standard 0-to-10 severity scale, and says both "can allow unauthenticated remote code execution." Unauthenticated means the attacker needs no account or password.

CVE	GitHub advisory	What goes wrong
CVE-2026-109618	GHSA-w8hw-w9fx-j79w	Running out of memory can stop PHP halfway through setting up a request. Cleanup code may then treat the half-built data as valid.
CVE-2026-109619	GHSA-6wmf-4rv5-p3rp	Some request data can outlive the memory behind it. The next request on the same worker process may use that stale data first.

A worker process is one of the long-running copies of PHP that a web server keeps alive to answer requests. Reusing workers is normal and fast, which is why leftover data from one request matters to the next.

Who is at risk

According to PHP's advisory, every installation that serves web requests may be affected. That includes PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP considers mod_php, the module that runs PHP inside Apache itself, the highest risk. It describes a "demonstrated exploit" where one unauthenticated request triggers the attack before any application code runs.

That detail matters for anyone relying on application-level defenses. A firewall rule inside WordPress or a framework never gets a chance to run.

PHP's advisory does not report attacks in the wild. Other reports are less settled. TechStartups says Cloudflare's chief technology officer saw early signs of attacks, though the scale is unclear. It also quotes watchTowr chief executive Benjamin Harris, who told BleepingComputer that both bugs are "CVSS10." That is higher than PHP's own 9.2. Gulf News, citing Reuters, reports that government websites in Europe and elsewhere went offline on Wednesday after the disclosure. It does not say whether attacks caused those outages.

Amazon later said its MadPot honeypots logged an exploit attempt on October 17, four days before this release, as covered in Amazon saw PHP2Shell attack attempts four days before disclosure.

Which PHP versions to install

Branch	Fixed release	Notes
PHP 8.5	8.5.12	Fixed
PHP 8.4	8.4.27	Fixed
PHP 8.3	8.3.36	Fixed
PHP 8.2	8.2.35	Fixed; branch reaches end of life on December 31, 2026
PHP 8.1, 8.0, 7.4	None	Minimal source patches only, on branches named PHP-8.1-CVE-2026-109618-109619 and similar
Older than 7.4	None	No fix from PHP

The source patches for 7.4, 8.0 and 8.1 are not packaged releases. Someone has to build them. Gulf News notes that some vendors may backport the fixes to older versions they still support.

PHP also lists partial mitigations, including turning off session.upload_progress.enabled and tightening request size limits. The advisory is blunt that these "do not make an installation safe." They only narrow the attack while a real update is being rolled out.

What this means for developers

Patch today, and patch the places you forget. The obvious server is rarely the only copy of PHP an organization runs.

• Check every runtime, not just the main site. Run php -v on each host. Then check container base images, CI runners, staging boxes and internal tools. A Docker image pinned to an old tag keeps the bug until someone rebuilds it.
• Restart after updating. PHP-FPM and Apache keep worker processes alive. A new package on disk does nothing until those workers restart, so confirm the running version afterward.
• Put mod_php hosts first. PHP names it the highest-risk setup, with an exploit that fires before your code runs. If you cannot update a mod_php server today, consider taking it offline until you can.
• Treat PHP 8.1 and older as an emergency upgrade. No official release is coming. The source patches buy time, but only if someone builds and maintains them. Ask your hosting provider or Linux distribution whether it ships a backport.
• Plan for PHP 8.2's end of life. The 8.2 branch stops getting security fixes on December 31, 2026. Moving to 8.4 or 8.5 now avoids a second scramble at the end of the year.
• Watch the logs. Reports of early attacks are unconfirmed, but the details are public now. Unusual crashes or out-of-memory errors in PHP workers deserve a closer look.