PHP2Shell, Three Weeks Later: What “Black October” Taught Us About Patch Speed

PHP2Shell fixes shipped October 21 and the attack traffic arrived within a day. Five lessons from the cleanup, the fixed versions by branch, and an emergency-patch runbook you can write this week.

The short answer: PHP2Shell (CVE-2026-109618 and CVE-2026-109619) was a pair of unauthenticated remote code execution flaws in a language that runs most of the web. Fixes shipped on October 21, 2026, and the attack traffic arrived almost immediately. Three weeks on, the organizations that came through cleanly had three things in common: they knew where PHP ran, they could patch outside the normal change window, and they were willing to take a site offline when they couldn’t. If you didn’t have all three, this is the post to read before the next one.

The press called it “Black October.” Former CISA director Chris Krebs put the scale in one line on CNBC: “3% of all critical vulnerabilities ever discovered have been found in the last month.” The UK’s National Cyber Security Centre called the scale unprecedented, while noting it had seen no sign of breaches at that point. Both things can be true, and that gap between exposure and damage is exactly where good process earns its keep.

What happened, briefly

  • Discovery. Researchers at Wiz and the AI security firm Calif found the flaws in August using frontier AI models, according to CNBC, and reported them privately.
  • Disclosure and fixes. Warnings spread on October 20 and PHP published fixed releases on October 21. PHP rates both flaws 9.2 on CVSS v4.0, and they affect nearly every PHP version from the last decade.
  • Government response. The NSA and the NCSC told website owners to take systems offline if they could not patch immediately. Government sites in France, Denmark, Finland, and the Netherlands went down as a precaution, and a UK minister reported 32 government services unavailable while fixes were applied.
  • Exploitation. Cloudflare reported “millions” of attempts across its network, with no evidence at the time that they had succeeded.
BranchFirst fixed releaseUpstream support
PHP 8.58.5.12Active
PHP 8.48.4.27Active
PHP 8.38.3.36Security fixes only
PHP 8.28.2.35Security fixes end December 31, 2026
PHP 8.1 and olderNo upstream releaseEnd of life

If your site still reports an older patch level on one of those branches, confirm with your host or distribution whether a backported fix is installed. If you can’t get a clear answer, treat the site as unpatched.

Five lessons from three weeks of cleanup

LessonWhat we sawWhat to change
The patch window is now days, not weeksFixes shipped October 21. Within a day, Cloudflare was reporting millions of exploit attempts across its network.Write down, before the next one, who can approve an emergency patch outside the change calendar and how fast.
You can't patch what you can't findMany teams spent the first day just working out which sites, containers, and vendor appliances ran PHP at all.Keep a living inventory of every internet-facing app with its runtime and version, not a spreadsheet updated at audit time.
"Take it offline" has to be a real optionThe NSA and the UK's NCSC told owners who couldn't patch immediately to take sites offline. The UK government did exactly that with dozens of services.Decide in advance which sites can go dark, who decides, and what the maintenance page says.
Version numbers lieLinux distributions backport fixes into builds whose version strings look old, and some servers hide their PHP version entirely.Verify against your vendor's advisory or package changelog, not just the banner. Record what you could and couldn't confirm.
End-of-life branches are the long tailPHP 8.1 and older got no numbered release. Those sites are relying on a distribution or hosting provider to backport, or on nothing.Treat every unsupported runtime as an open finding with an owner and an upgrade date. PHP 8.2 joins that list on December 31.

Why this keeps happening now

PHP2Shell wasn’t an isolated bad week. It landed between Anthropic’s limited release of its Mythos model in April, which we covered in our post on Glasswing and patching faster, and OpenAI’s GPT-6 Cyber in November. Each step makes it cheaper to find serious bugs in old, widely used code.

That cuts both ways. The same tools that found PHP2Shell before attackers did will also help attackers turn the next patch into a working exploit within hours. The practical consequence for defenders is simple: assume the time between “fix published” and “mass exploitation” is about a day, and build your process around that number.

An emergency-patch runbook you can write this week

  1. Inventory. List every internet-facing site and API with its runtime, version, host, and owner. Include vendor appliances and marketing microsites.
  2. Pre-approval. Agree in writing that a critical, remotely exploitable flaw on an internet-facing system can be patched without waiting for the next change window. Name who approves.
  3. Offline plan. For each site, decide whether it can be taken down for a day, and prepare the maintenance page in advance.
  4. Compensating controls. Know how to add a WAF rule or restrict access by IP quickly while the patch is tested.
  5. Verification. After patching, confirm the running version from the outside and record the evidence. Auditors and insurers will ask.
  6. Retire the long tail. Put every end-of-life runtime on a dated upgrade plan. For PHP 8.2, the date is December 31, 2026.

Know Where Your PHP Stands

The Scan Ninja PHP Exposure Assessment gives you a written answer for one website or PHP environment: which version you run, whether it carries the PHP2Shell fixes, which advisories apply, and what to fix first. For ongoing coverage, Managed Vulnerability Remediation takes you from findings to verified fixes.

Or see Managed Vulnerability Remediation

Sources

Related Resources