PHP Ships the PHP2Shell Fixes a Day Early After a Leak, and Attackers Were Probing Before the Patch Landed

PHP released fixes for both PHP2Shell flaws on Wednesday, October 21, a day ahead of schedule. Versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 repair CVE-2026-109618 and CVE-2026-109619, which PHP rates 9.2 on the CVSS v4.0 scale and which can give an unauthenticated attacker code execution on a web server. The PHP Foundation says it pulled the date forward from October 22 after the two CVE identifiers leaked on October 20, and that two more things then went wrong: Calif, one of three teams that found the bugs, mistakenly published a video of its working proof of concept, and Chainguard published container images containing the fix more than six hours before the release. Cloudflare and others report attack traffic from before the release. None of the sources we read reports a confirmed break-in of a specific server.

Our pre-release snapshot ended with six open questions. The release answers most of them. It also leaves a large group of sites in a harder position: PHP 8.1 and older get no upstream release, and 36.4 percent of the WordPress sites that report a PHP version run 8.1 or older.

What the release settled

The table sets what was claimed before the release against the record now. The sources are PHP’s security advisory and its two GitHub advisories, the Foundation’s account, NVD and the finders’ own write-ups.

What the patch changes

PHP’s advisory for CVE-2026-109618 says the patch removes the longjmp() call that PHP used to abandon a request when it ran out of memory. In its place is a delayed, graceful stop at the next VM safe point, plus an immediate hard exit if memory use reaches a second, higher threshold. The advisory for CVE-2026-109619 says the complete patch resets the wider set of request state that could outlive a request, and the ChangeLog lists both fixes under one entry, “Avoid state corruption via bailout.” Because the new hard limit ends the process, The Hacker News advises checking memory_limit and post_max_size against what your applications need once you have updated.

The advisory is blunt about stopgaps: “There are no complete mitigations, updating is the only safe choice.” The partial measures it lists “do not make an installation safe.” For the first flaw they include memory_limit=-1 set where applications cannot override it and request-size limits at the web server or proxy. For the second they include session.upload_progress.enabled=0 in php.ini, the FPM pool or the server configuration (not ini_set() or .user.ini) and, on PHP 8.5, fatal_error_backtraces=0. That settles the morning’s argument about the setting that circulated first: turning off session upload progress blocks only the confirmed session paths of the second flaw.

How the disclosure came apart

The Foundation says coordinated disclosure “worked well until 2 days ahead of the targeted release date.” The sequence below comes from its account, the finders’ write-ups and the vendors’ logs, in UTC.

Chainguard’s release is the disputed link. The Foundation says the company “unilaterally broke the embargo” even though, like other distributors, it had received the patch early so its users could update at disclosure, and adds that “Any attacker could now study the fix in binary form while every other PHP user was still waiting for the release.” Chainguard’s chief executive, Dan Lorenc, told Recorded Future News that he began to see exploitation attempts the night before and made a judgment call to release the information. “It’s not us versus them here,” he said. “It’s all of us working together to minimize risk for the industry.” He added: “I think the PHP maintainers did a great job here.” We could not find a Chainguard post on the episode.

The Foundation is just as direct about the delay on its own side. A PHP developer found the first signs of the out-of-memory problem in 2024 while fixing an issue from a Quarkslab security audit, but the competing fixes each carried compatibility, denial-of-service or extension-coordination costs, and work on a fix stalled and restarted for months. “We won’t pretend otherwise: the delay was a structural failure, caused by both the security team’s decision process and its lack of resources.” Calif’s write-up traces the same bug family from a 2004 memory-limit flaw through a 2020 bug report (#78876) and a 2024 audit finding whose exploitation was unproven. By our count, 71 days passed between Calif’s first report on August 11 and the release, and 58 days between Wiz’s report on August 24 and the release.

Who found it, and how much the AI mattered

OpenAI says Calif found a critical flaw with its GPT-5.6 Sol model under Patch the Planet and that Wiz independently found and reported both vulnerabilities. Wiz says it used Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol and that, with frontier models and the right tools, “a single researcher completed in a week what previously would have taken a world-class team months of work.” OpenAI writes: “To our knowledge, frontier AI found these vulnerabilities before attackers did.” It adds that in the PHP response it engaged “the White House’s Super Intelligence Force,” the Office of the National Cyber Director and CISA; we covered the force’s launch earlier this month.

Calif’s own account is more guarded. Its researcher writes that “No special harness, or access to models that weren’t generally available to everyone were used in the initial bug discovery,” that the principle of knowing your target is “still as applicable as ever, even in the LLM dominated VR age,” and that “everyone and every lab had already done extensive AI assisted audits of this target” before the first finding. The Foundation says it had scanned PHP earlier this year with Anthropic’s Claude Mythos and later added OpenAI’s Daybreak Red, that AI now helps it validate and group reports (it has published 15 CVEs since July 1 and worked through more than 100 reports that were invalid, duplicates or not reproducible), and that “a person makes every call and works on every patch.” Wiz warns that “there are other tracked, and likely untracked, variants of this issue in the PHP codebase,” and says the patch “eliminates all variants in the patched release.” For two other recent cases of AI-assisted findings in widely used open source, see our reports on Anthropic’s OSS Scanner and curl’s record 24-fix release.

Where exploitation stands

Attempts are well documented; a confirmed compromise is not. Cloudflare says it “observed attack traffic targeting our customers” and watched attackers mutate their payloads to get past its rules, which went on by default for free and paid WAF customers at 03:02 UTC. Patchstack’s hosting partners reported exploitation incidents at 07:34 UTC, but its own telemetry at 13:57 UTC showed “only probing attacks, with no hard evidence of breaches yet.” Hadrian wrote at 11:35 UTC, “We are now seeing php2shell exploited in the wild at scale,” mostly through session upload progress, and said again at 14:35 UTC that “Exploitation is still happening at scale”; its page gives no count of successful intrusions. watchTowr reported no exploitation in the wild at 11:26 UTC and active attempts by 14:19 UTC, according to The Hacker News, and told The Register that “vibecoded PoCs” were hitting its sensors: “Whilst nobody has been successful to date, we don’t expect that will last long.” Vega reports attempts that use the public proof of concept.

PHP’s own position is that its team “closely monitored and inspected appearing PoCs after the leak but did not identify any functional exploits at the time of release/public disclosure.” Neither flaw was in CISA’s Known Exploited Vulnerabilities catalog when we checked at 19:35 UTC, and CISA’s SSVC entry in NVD recorded exploitation as none at 14:34 UTC, which is a snapshot rather than a verdict. The most visible consequences in the reporting so far are precautionary shutdowns. The Register reports that “Finnish government services and websites belonging to the Dutch parliament, cybersecurity authorities, and data protection regulator were taken offline as a precaution,” and WIRED, citing Reuters, adds French government sites and the Port of Rotterdam. They came amid advice from NSA Cyber, CERT-EU and others to isolate or pull exposed systems, while PHP’s own text says only that nothing short of updating is a complete mitigation.

Who still has no easy fix

WordPress.org’s published statistics, fetched at 19:35 UTC on October 21, put the sites that report a PHP version like this: 36.4 percent on 8.1 or older (including 16.1 on 7.4, 10.7 on 8.1 and 3.8 on 8.0), 23.8 on 8.2, 26.6 on 8.3, 9.3 on 8.4 and 3.9 on 8.5. The figures show branches, not patch levels, so they cannot say who is protected. WordPress says the flaws are “not specific to WordPress, and no WordPress update is required,” and tells site owners that “Versions before PHP 8.2 no longer receive security updates.”

Vendors are the other route. Ubuntu says it “has released fixes for the affected packages for all supported releases,” and its bulletin lists patched packages from 26.10 down to php5 on 14.04 through Expanded Security Maintenance. The fixed package for 22.04 is numbered 8.1.2-1ubuntu2.28, so a version string alone says little. Debian’s tracker lists fixed packages for bookworm (8.2.35-1~deb12u1) and trixie (8.4.27-1~deb13u1) and, at 19:35 UTC, still showed unstable as unfixed. On Docker Hub, the official php tags for 8.2.35, 8.3.36, 8.4.27 and 8.5.12 were last pushed between 17:22 and 18:59 UTC on October 21, while the 8.1 tags were last pushed between December 31, 2025 and January 2, 2026 and the 8.0 and 7.4 tags in 2023 and 2022, so images pinned to those tags carry no upstream fix.

PHP’s advisory first told users of the volunteer-run Remi repository that it “will not have updates today”; the project removed that sentence at 14:18 UTC, and Remi’s blog showed no release post when we looked at 19:36 UTC. PHP 8.2 itself gets security fixes only until December 31, 2026, according to the supported-versions page.

What to do today

1. Update the PHP that serves web requests, not only the command-line binary, to 8.2.35, 8.3.36, 8.4.27 or 8.5.12, or to your vendor’s patched package, and restart Apache, PHP-FPM and any long-running workers.
2. If you run 8.1 or older, ask your vendor for its backport, build from PHP’s backport branches, and plan the move to a supported branch.
3. Rebuild container images from a patched tag, and check the base image that your application image inherits.
4. After updating, review memory_limit and post_max_size, because the patch adds a hard stop.
5. Look for traces from before the patch. Wiz lists unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses, unexpectedly large or malformed PHPSESSID response cookies, and unexplained PHP worker churn.

To see the newest release in each supported branch, run the same loop we gave in the snapshot:

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 19:36 UTC, after the release:

8.2.35 21 Oct 2026
8.3.36 21 Oct 2026
8.4.27 21 Oct 2026
8.5.12 21 Oct 2026

Ubuntu’s bulletin gives this check for installed PHP packages on its releases:

apt list '?installed ?name(^php[0-9.]+$)'

Sources and method

We read PHP’s security advisory and ChangeLog on php.net, the two GitHub security advisories and the three backport branches through the GitHub API, the web-php repository’s commit log, the PHP Foundation’s post, and the write-ups from Calif, Wiz, OpenAI, Cloudflare, Patchstack, watchTowr, Hadrian, Ubuntu, The Register, WIRED, The Record, The Hacker News and SecurityWeek. We queried NVD’s REST API and CISA’s KEV feed directly, read Debian’s tracker, WordPress.org’s PHP statistics and the Docker Hub API, and read the X posts from NSA Cyber, WordPress and Vega through a public mirror. We did not run or request any exploit code and left out exploitation mechanics beyond what PHP’s own notice says. Reuters was not reachable by script, so its reporting is cited through WIRED. Figures that other outlets attribute to VirusTotal and Cisco Talos are left out because we could not find the primary reports. The release-check loop was run with python in place of python3, which this Windows machine lacks. Details of this story were still changing when we published.