PHP schedules emergency fix for two critical 9.2 flaws

The PHP security team will publish an out-of-cycle security release at 14:00 UTC on October 21, 2026, for two flaws it rates critical. Researchers say the bugs allow remote code execution, and details leaked a day early. Anyone running PHP should be ready to patch the moment the release lands.

PHP is the language behind WordPress, Drupal and a large share of the web's server code. An out-of-cycle release is one that ships outside the project's normal release calendar, which PHP reserves for urgent fixes.

What the PHP security team has announced

The PHP.net notice, posted on October 20, says little on purpose. It names two vulnerabilities and rates each 9.2 on CVSS v4.0, the standard 0-to-10 severity scale. It gives no CVE numbers, no description and no version numbers. The affected and fixed versions "will be published with the release," the notice says.

The team also left itself room to move faster. It says it may ship early if the details become public or if attacks start. "All PHP users are encouraged to prepare now so they can upgrade as soon as the release is available," the notice says.

LWN, a long-running Linux and open-source news site, passed the warning on the same day. It told anyone running a PHP site to get ready for the update.

What leaked, and what is still unconfirmed

The Hacker News reports that researchers call the pair "php2shell," a name PHP did not use. The security firm watchTowr says the flaws allow remote code execution, meaning an attacker could run commands on the server. On October 20, watchTowr said on X that a leak about them was real. It added that the flaws were under embargo, a period when details stay private until a fix ships.

That leak was a post on Hacker News, the tech forum. It said disclosure was planned for Thursday, October 22, and claimed every version from PHP 5 onward is affected. That scope is unconfirmed. In the words of watchTowr's FAQ, it "has not been confirmed by an official vendor advisory."

Researchers attach two IDs to the flaws: CVE-2026-109618 and CVE-2026-109619. PHP's notice names neither.

A self-published write-up on jackalsyn.com, by a researcher using the name J4ck3LSyN, ties those IDs to a use-after-free bug in session.upload_progress. A use-after-free happens when a program keeps using memory it has already released. The feature itself tracks file-upload progress in a user's session.

That write-up rates its own findings far lower than PHP does: 5.3, or Medium, for one path and 0.0 for another. It reproduced the bug only on Apache with mod_php in prefork mode, and it showed no code execution. Nothing confirms it describes the same bugs PHP rated 9.2.

Which PHP versions will get fixes

The Hacker News says only the supported branches, 8.2 to 8.5, will get fixes. Alpine Linux and security researcher Kevin Beaumont track expected version numbers, which PHP has not confirmed.

Branch	Current release	Support status	Expected fix (unconfirmed)
PHP 8.5	8.5.11	Active support to December 31, 2027	8.5.12
PHP 8.4	8.4.26	Active support to December 31, 2026	8.4.27
PHP 8.3	8.3.35	Security fixes only to December 31, 2027	8.3.36
PHP 8.2	8.2.34	Security fixes only to December 31, 2026	8.2.35
PHP 8.1 and older	n/a	End of life	No fix from PHP

The old branches are a big share of the web. A Shodan count by Mallory on October 20, cited by The Hacker News, found about 884,000 internet-facing hosts reporting PHP 8.1 or older. That is 59% of about 1.5 million hosts that report any version. About 740,000 more report PHP with no version. These are banner counts, not confirmed vulnerable systems.

No attacks have been reported so far. Huntress, a security company, saw no exploitation as of October 20 and knew of no public exploit code. The flaws are not on CISA's list of known exploited vulnerabilities. That window may be short: Akamai saw attack attempts within 24 hours after CVE-2024-4577, an earlier PHP flaw, went public in June 2024.

What this means for developers

Find every copy of PHP first. Huntress and CERT-EU both advise an inventory that includes bundled copies, such as PHP inside container images, appliances and hosting panels. A server you forgot about is the one that gets hit.

Patch internet-facing systems first, as soon as the release appears at 14:00 UTC. It has since shipped as PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If you install PHP from a Linux distribution or a container base image, check when that source publishes its rebuilt package. That can lag behind php.net.

Plan for the end-of-life branches now. PHP 8.1 and older will get no fix from the project. CERT-EU says to "consider isolating internet-facing applications from public networks until a fix is available." The other options are an upgrade, a VPN, or a web application firewall in front of the site.

Treat the unofficial workaround with care. The jackalsyn.com write-up suggests setting session.upload_progress.enabled = Off. PHP has published no workaround, and that write-up may not describe the bugs PHP is fixing. Most apps do not need the setting unless they show upload progress bars, so turning it off is a cheap stopgap, not a fix.

Watch for signs of compromise this week. The Hacker News passes on guidance to alert when a PHP process starts a shell or a download tool. PHP applications have had a busy month: Drupal shipped a fix for a critical Field UI flaw on October 14.