Skip to content
NewsIncident

Attackers began exploiting PHP2Shell before PHP's patch even shipped

· by Pondero Newsdesk

The short version

Cloudflare and Patchstack say attackers probed the PHP2Shell flaw hours before PHP's October 21 fix went out, and a narrower follow-up bug surfaced two days later.

Attackers began exploiting PHP2Shell before PHP's patch even shipped

Cloudflare and the security vendor Patchstack say attackers started probing the PHP2Shell vulnerability before PHP's own fix went out on October 21, 2026, and that exploitation attempts continued after the patch shipped. That is new since Pondero's original report on the disclosure, which covered how OpenAI and Wiz found the bugs and the NSA's warning to pull unpatched sites offline.

What happened

PHP2Shell is the name researchers gave to two critical remote-code-execution flaws, CVE-2026-109618 and CVE-2026-109619, rated 9.2 on CVSS v4.0 and present in every PHP version back to 5.4. Details leaked on October 20, two days ahead of the planned disclosure, and PHP shipped fixed releases (8.5.12, 8.4.27, 8.3.36, and 8.2.35) at 13:52 UTC on October 21 per the PHP Foundation's advisory archive. Cloudflare said it had already rolled out default web-application-firewall protection to all customers by 3:02 a.m. UTC that day, roughly nine hours ahead of the public release, after its own telemetry picked up attack traffic against customers during the leak window per Cloudflare's blog post. Patchstack logged multiple active-exploitation incidents reported by hosting partners at 07:34 UTC, nearly six hours before PHP's patch shipped, though it noted its own telemetry just after the release showed mostly probing rather than confirmed breaches per Patchstack's live incident timeline. SOCRadar's updated writeup separately cited the security firm Aikido reporting in-the-wild exploitation, while noting that neither Aikido nor Patchstack had published technical attack details and that the flaws had not yet appeared on CISA's known-exploited-vulnerabilities catalog as of October 21 per SOCRadar's analysis.

Unpatched PHP installs are already inside the attack window

Because the vulnerability leaked before the fix was ready, attackers had a head start that the usual patch-then-exploit timeline does not allow. Operators whose PHP servers sit behind no WAF have one real move: patch now, since nothing else stands between a vulnerable server and a working exploit. Cloudflare's WAF rules block known exploit patterns by default for customers on its network, and the company said attackers were already mutating payloads within hours to try to slip past those rules, which is why it built a new detection capability that checks both the request and the server's response in the same transaction per Cloudflare's blog post. A firewall only covers traffic that passes through it, though, so any server running an affected PHP version without Cloudflare or a comparable control in front of it depends entirely on whether an administrator has applied PHP's update. Sites pulled offline on the NSA's advice, noted in Pondero's prior report, sidestepped this window; sites left running on old, unpatched PHP did not.

What to watch next

PHP published a narrower follow-up advisory on October 23 for a related issue, CVE-2026-115560, in the session-upload-progress feature. It affects even the patched 8.5.12 release but needs an unusual combination of application settings to trigger, which PHP called unlikely in practice while it prepares a full fix for its next regular release per the PHP Foundation's advisory archive. Watch whether CISA adds CVE-2026-109618 and CVE-2026-109619 to its known-exploited-vulnerabilities catalog, and whether Aikido or Patchstack publish the technical detail needed to show how many of the reported incidents were confirmed breaches rather than scans.

Sources