PHP Warns of Two Critical Flaws and Sets a 14:00 UTC Patch, but the Leak, the Score and the Exploitation Reports Do Not Agree

PHP’s security team says it will ship a security release at 14:00 UTC on Wednesday, October 21, to fix two critical vulnerabilities that it rates 9.2 under CVSS v4.0, and that it may release sooner if details become public or exploitation appears. Information about the flaws leaked on October 20, ahead of the coordinated disclosure, and by 07:43 UTC on October 21 Cloudflare’s chief technology officer was saying the company was already seeing early attacks. PHP’s notice names no CVE identifiers, affected versions or mitigations, so nearly everything else in circulation, from the “PHP2Shell” label to the claim that every PHP version since 5 is affected, comes from outside the project, and those outside accounts do not line up.

This article is a snapshot taken before the release. At 10:30 UTC on October 21, php.net’s releases endpoint still listed the September 24 releases (8.2.34, 8.3.35, 8.4.26 and 8.5.11) as the newest in each supported branch, so there was nothing to install yet. The last section shows how to read the release against the open questions below once it lands.

What PHP has said

PHP’s notice reached the php.net site repository at 19:25 UTC on October 20 and the internals mailing list at 19:32 UTC, where Jakub Zelenka posted it under the signature “The PHP security team.” It says the release “addresses two critical vulnerabilities (both rated CVSS v4.0 9.2, Critical),” asks users to “prepare now so you can update as soon as it is available,” and adds: “We reserve the right to release earlier if details of either vulnerability become public, or if we see evidence of active exploitation in the wild.” The front-page version of the notice also promises that “Full details, affected versions, and the fixed versions will be published with the release.”

The notice does not identify the flaws. CVE-2026-109618 and CVE-2026-109619 come from the leak, and no public record carried them when we checked at 10:30 UTC: the NVD API returned no results for either, the CVE Services API answered that neither record exists, and the CISA Known Exploited Vulnerabilities catalog (version 2026.10.20) listed neither.

How the leak unfolded

The earliest account we found is a post on the Hacker News forum that has since been deleted. BleepingComputer, which saw it, says the post claimed two critical PHP flaws would be disclosed on October 22, scored both at 10.0, said they reached back to PHP 5, and named both CVE identifiers. Sansec’s timeline puts that post at 15:20 UTC on October 20. The rest of the sequence, in UTC:

Where the accounts disagree

PHP’s notice is short, and leaked claims and vendor write-ups fill the gaps in ways that diverge on six points.

PHP published the scores but not the vectors, so the 9.2 versus 10.0 gap cannot be settled yet. We recomputed reference points with the open-source cvss library (version 3.6). In CVSS v4.0, a network, low-complexity, no-requirements, no-privilege, no-interaction vector with high impact on the vulnerable system scores 9.3. Making attack requirements present (AT:P) or attack complexity high (AC:H) gives 9.2, and 10.0 needs high impact on subsequent systems as well. In CVSS 3.1 the same network vector scores 9.8 and reaches 10.0 only with a changed scope. A 9.2 and a 10.0 cannot describe the same vector, so the two figures should not be treated as rounding variants of one rating.

What is said about the exploit tool

Ars Technica says the leaked report included a video of an exploit tool called PHP2Shell running code on servers hosting ten application builds, among them WordPress 7.1.3, Magento 2.4.9 and Drupal 11.4.10, and that attempts to find the report itself were unsuccessful. Huntress says a short exploitation video was briefly posted online and then removed, and that it has not built or reproduced a proof of concept and is not aware of public exploit code. Sansec says a screenshot of the tool, credited to Calif.IO, leaked alongside the advisory, and that the tool’s banner claims it works against every PHP release from 5.4.0 on. Dormann wrote that Calif “may have a PoC called php2shell that works against WordPress,” and Beaumont wrote at 08:19 UTC that the screenshot Dormann posted “is real.” We found no statement from Calif on its website.

watchTowr says it believes it reproduced CVE-2026-109618 and is withholding technical detail until patches ship, and the developers of The SEO Framework wrote on X that they “replicated today’s PHP session exploit.” Taken together, the accounts are consistent with working exploit code existing outside PHP’s control, but every one of them is secondhand, and none comes from PHP. Beaumont also wrote that PHP “probably has to bring forward the release” because details are now circulating, and he blames security vendors that had advance notice for passing details to customers; we could not verify that.

Who gets a patch

PHP’s supported-versions page lists four supported branches. Version 8.2 receives security fixes until December 31, 2026 and 8.3 until December 31, 2027; 8.4 stays under active support until December 31, 2026 and 8.5 until December 31, 2027. Anything older is end of life, and the page warns that users of such releases “may be exposed to unpatched security vulnerabilities.” Patchstack says older branches “may not receive patches” and calls that unconfirmed until the release, and Huntress writes that reporting suggests only currently supported branches will get a fix.

For WordPress the exposure is easy to size. WordPress.org’s published PHP version statistics, which we fetched at 10:30 UTC, break the reporting sites down like this:

Within the first row, PHP 7.4 alone accounts for 16.1 percent of sites and PHP 8.1 for 10.7 percent. A further 0.02 percent run PHP 8.6 pre-releases, which the table leaves out. The table says nothing about who applies the fix. Wordfence points out that PHP is server software: “Updating WordPress, your plugins, or your themes does not change the version of PHP your server runs.” On most managed hosting the host updates PHP, on a VPS or dedicated server the owner does, and packages from an operating system, a control panel or a container image “may arrive on a different schedule from the official php.net release.” Our report on Drupal’s October 14 core fix, where unsupported branches got no patch, is a recent reminder that end-of-life software can simply stay exposed.

Distribution channels matter too. The PHP Foundation said on X at 08:48 UTC that anyone relying on the volunteer-maintained Remi repository (rpms.remirepo.net) should “move to distro packages or building from source now” so they can apply updates immediately, because “The repo will not have updates today.” Sansec notes that the repository is common on RHEL-based servers.

Stopgaps, and who says they work

The advice that circulated first was to turn off PHP’s session upload progress feature, and a PHP core developer says that is not enough. At 01:44 UTC on October 21 a Mastodon user, whitequark, suggested that setting session.upload_progress.enabled to off might patch the flaw, then edited the post to add “this is not actually enough according to a php core dev.” At 02:13 UTC Gina Peter Banyard, a PHP core developer, replied: “The only thing I can say is that the only mitigation is patching / upgrading PHP.” She added that taking a server offline for a day “might be the most sensible thing to do,” though that is “far from a reasonable thing to demand for most people.”

The vendors’ advice has since been hedged. Patchstack now lists turning off upload progress and blocking multipart requests where they are not needed, and says these “are only partial mitigations and do not stop exploitation.” Sansec still lists the setting, together with strict session mode, but now cites Banyard, tells readers not to rely on the setting alone, and calls its settings “no guarantee.” The SEO Framework’s developers wrote that disabling sessions does not prevent the exploit they replicated. Turning upload progress off is harmless hygiene, since the PHP manual already advises applications without upload progress bars to “consider disabling this option” because the feature writes client-supplied file and field names to the session store, but on the evidence so far it is at best a partial measure.

Other stopgaps depend on where the traffic goes. Cloudflare’s Knecht says PHP sites behind Cloudflare already have an initial set of WAF rules for “the known exploit vectors,” available to all customers including the free plan, and calls them “a STOPGAP only.” Sansec adds that such rules protect a site only if its origin server refuses connections that do not come from Cloudflare, because an attacker who knows the origin IP address can send requests to it directly. Beaumont wrote that restricting PHP’s ability to execute commands with AppArmor or SELinux is “a really good mitigation” that works against these CVEs, and Huntress, citing Florian Roth, expects exploitation to “show up as suspicious child processes spawned by PHP,” such as shells, interpreters or download tools launched by php-fpm, php-cgi, httpd or apache2. We could not verify the AppArmor and SELinux claim or the detection pattern. CERT-EU’s advisory is blunter: where immediate patching is not feasible, organisations should consider “isolating internet-facing applications from public networks until a fix is available.”

What to check at 14:00 UTC

When the release lands, read it against the open questions: which branches and versions are named, whether anything older than 8.2 gets a fix, the CVE identifiers and vectors, whether the score is 9.2 or 10.0, whether upload progress or sessions are mentioned, and whether PHP says it has seen exploitation. To see the newest release in each supported branch, this loop queries php.net’s releases endpoint and works anywhere with curl and Python 3:

for v in 8.2 8.3 8.4 8.5; do
  curl -s "https://www.php.net/releases/index.php?json&version=$v" \
    | python3 -c "import sys,json; d=json.load(sys.stdin); print(d['version'], d['date'])"
done

Output at 10:30 UTC, before the release:

8.2.34 24 Sep 2026
8.3.35 24 Sep 2026
8.4.26 24 Sep 2026
8.5.11 24 Sep 2026

After the release the numbers and dates should change. Compare them with php -v on the machine that serves your site; the command-line binary can differ from the one behind your web server, so also check your host’s control panel or a phpinfo() page. Distribution packages follow their own schedules: Huntress advises checking “your Linux distribution and hosting provider for backported packages.”

PHP published its September 24 advisories as GitHub security advisories on php-src (for example CVE-2026-93682, an out-of-bounds read in the HTTP stream wrapper), so if it follows the same pattern the CVE identifiers and fixed versions will appear in that listing. Wordfence advises taking a fresh backup of site files and the database, and having a staging test ready, before the release; if Sansec’s forecast holds, a maintenance window that opens after 14:00 UTC will be racing attackers.

Sources and method

We read PHP’s notice on php.net, in the php-src and web-php repositories through the GitHub API, and in the internals list archive at externals.io. We read the Mastodon and X posts, including those from Cloudflare’s chief technology officer, the PHP Foundation, The SEO Framework and PHP core developer Gina Peter Banyard, through the Mastodon API and a public X mirror, and the write-ups from Patchstack, Sansec, watchTowr, Huntress, Wordfence, CERT-EU, Ars Technica, BleepingComputer and SecurityWeek. We queried the NVD REST API, the CVE Services API and CISA’s KEV JSON feed directly, read the supported-versions page and the session and PHP-FPM manual pages, and fetched WordPress.org’s PHP version statistics. The CVSS reference scores were computed with the open-source cvss library. We did not link or rely on the third-party write-up that Beaumont mentions, and nothing in this article has been confirmed by PHP beyond its own notice.