How a Day-Early Leak of Two PHP Flaws Tests the Embargo Behind Coordinated Disclosure

PHP's security team had set two critical fixes for Wednesday 21 October at 14:00 UTC. Its advance notice, dated 20 October and titled as an upcoming critical security release, did not name the bugs. Details of the flaws reached the public the day before the release, through a post that was later taken down and screenshots that spread on social media.

PHP's notice said full details, affected versions and fixed versions would be published with the release. For the two flaws now tracked as CVE-2026-109618 and CVE-2026-109619, that date was about a day away when the material surfaced.

What the Advance Notice Committed PHP To

The notice described two critical vulnerabilities, each rated 9.2 under CVSS v4.0. It gave no CVE numbers, names or descriptions, and said affected and fixed versions would be published with the release.

It also set the conditions for an early release. PHP reserved the right to ship sooner if details of either flaw became public or if evidence of active exploitation emerged.

The notice asked users to prepare now so they could upgrade as soon as the release was available. Huntress advised inventorying every PHP install before the fixes were out.

How the Details Reached the Public First

Huntress reports that a post claimed the flaws were headed for disclosure on the morning of 20 October. The post was taken down, but screenshots spread on social media. watchTowr then confirmed the leak and said the flaws were real.

Sansec gives the time of the post as 15:20 UTC on 20 October, so the accounts differ on when it appeared. Both describe it as a Hacker News post.

The screenshots included an exploit tool called PHP2Shell. Sansec says its banner claims the tool works against every PHP release from 5.4.0 on, and says the bugs affect all web servers running PHP 5.4 or later. Wikipedia describes leaked claims of code execution on sites running PHP 5 through 8 as unconfirmed.

How PHP's Support Windows Decide Who Gets the Fix

PHP's supported-versions page gives each branch two years of active support, followed by two years of security-only support. Active support covers reported bugs as well as security issues, with regular point releases. Security-only branches receive fixes for critical security issues, released as needed.

As of 21 October 2026 the page lists 8.4 and 8.5 as in active support, with 8.4 active until 31 Dec 2026 and 8.5 until 31 Dec 2027. It lists 8.2 and 8.3 as security-fix only. Security support for 8.2 ends 31 Dec 2026, and for 8.3 it ends 31 Dec 2027.

PHP 8.1 does not appear in that table. The end-of-life page gives 31 Dec 2025 as its end date, with 8.1.34 as the last release, and advises users of end-of-life branches to upgrade because older releases may expose them to security vulnerabilities. Sansec reads the policy as PHP supporting 8.2 and later, so servers on 8.1 or older would get no official release for these flaws.

Huntress says reporting suggests PHP 5 through 8 may be affected, and that only currently supported branches will get a fix. As of 20 October, PHP had not published affected or fixed version numbers, which it said would come with the release. On 21 October it released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and its security team published minimal source backports for 7.4, 8.0 and 8.1 for people who build PHP from source. The end-of-life table lists branches back to 3.0, and the range in reporting includes several end-of-life branches, which Huntress says would be left with no patch at all.

Exploitation Claims and Who Made Each

Cloudflare reported early attacks against PHP sites at 07:43 UTC on 21 October, according to Sansec. It deployed web application firewall rules for all customers, including the free plan. Its CTO, Dane Knecht, described those rules as a stopgap.

Huntress made a narrower claim. As of 20 October it had not seen exploitation of the flaws in its partner environments. The two statements cover different days, so they do not directly contradict each other.

Sansec forecast mass attacks within 15 minutes of the release. That is its expectation, not a reported event.

The Race Between Patching and Exploit Building

Sansec's list of steps before the patch includes blocking multipart/form-data requests at the web server. That stops PHP from parsing those requests, but it breaks file uploads and may break some cart or checkout forms, so Sansec recommends testing with a test order. It also lists putting the site behind Cloudflare and accepting traffic only from Cloudflare's address ranges, and taking the site offline.

Sansec says the maintenance modes built into Magento and WordPress do not help, because PHP still parses each request. If a site cannot go offline, Sansec says it can be made read-only by rejecting every method except GET and HEAD. It says the two PHP settings it lists, which turn off session upload progress and turn on strict session mode, give no guarantee.

Banyard, a PHP core developer, wrote on 21 October at 02:13 UTC that patching is the only mitigation, according to Sansec.

Sansec reports that several Dutch government and media sites went offline before the release.

What Repackaged PHP Means for Patch Timing

Some servers install PHP from third-party repositories. Sansec reports that one third-party PHP package repository would not publish updates on 21 October, according to a warning from the PHP Foundation at 08:48 UTC. Sansec advises switching to distribution packages or building from source in that case.

Sansec also advises asking a hosting provider to backport the fix or to move to a supported version, for any server still on 8.1 or older.

Huntress advises checking distributions and hosts for backported fixes, and inventorying PHP bundled inside vendor software, control panels and content management systems. It also suggests alerting when PHP worker processes start shells, interpreters or download tools, and preserving web server and PHP logs if you find something.

PHP released the fixes on 21 October in 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and its advisory says updating is the only safe choice.