Black October Was Not Won by AI. It Was Won by Inventory.

By Aleem Ul Hassan. Last updated October 27, 2026.

My first read of Black October was the same as everyone else’s. The attackers have AI now, so the defenders need AI too. Buy the AI defense, close the gap. Then I read Fastly’s timeline of the first 24 hours, and the story changed shape.

Here is the short answer. PHP2Shell is a pair of AI-discovered flaws in the core PHP engine that let anyone run code on a server without logging in. PHP sits under roughly 70% of websites, so the patch on October 21, 2026 set off a global scramble, governments told operators to pull unpatched sites offline, and the week got a name: Black October. AI made the attack faster. What separated the people who coped from the people who panicked was not AI. It was knowing where PHP ran.

That matters to me in a very practical way. A good share of the client sites I have built over the years run on WordPress, which means they run on PHP. The ones on hosted builders like Webflow or Framer were someone else’s patch to ship. The self-hosted ones were mine to think about.

What was Black October?

Black October is the name the security press gave October 2026, when several serious incidents landed inside one week. The headline was PHP2Shell, two critical PHP flaws patched on October 21. Around it sat a poisoned LiteLLM release, weak certificate authority keys at eMudhra, and a critical GitLab fix. The common thread was AI speeding up both discovery and exploitation.

CNBC, The Guardian and The Washington Post all ran the label on October 23. The Wikipedia summary of Black October lists the cluster:

Date (2026)	Incident	Why it mattered
Oct 17	eMudhra reports weak keys on eight intermediate CA certificates	Browsers had to revoke them; roughly 30,000 certificates need replacing
Oct 21	PHP2Shell patched (CVE-2026-109618, CVE-2026-109619)	Unauthenticated remote code execution in core PHP
Oct 21	LiteLLM 1.107.0 published with an infostealer	An AI gateway that holds every model provider key
Oct 21	GitLab fixes a remote code execution flaw in self-managed instances	Reported as CVSS 10.0

The quote that captured the mood came from John Milinovich at Figma, cited by CNBC: several dozen attacks in two days that “in isolation, would each have been the worst to happen in an entire calendar year.”

What is PHP2Shell, and how did AI find it?

PHP2Shell is two use-after-free style memory bugs in the PHP engine itself, not in any plugin or app. One corrupts memory when a request is timed to hit PHP’s memory limit during a multipart upload. The other leaves stale state behind for the next request on the same worker. Wiz showed unauthenticated code execution on stock WordPress, Drupal and Joomla images.

Which AI models found it?

The AI part is not marketing. According to Wiz’s write-up, its team used its own Wiz Atlas agent plus Gemini 4 Argon and GPT-5.6 Sol, and found the first bug on August 19. Separately, the testing firm Calif found one flaw with GPT-5.6 Sol as part of OpenAI’s Patch the Planet work, per TechCrunch. The bugs reach back to PHP 5.4. They sat in shipped code for more than a decade.

Wiz’s own line is the uncomfortable one: the hard part of adapting an exploit across PHP versions and memory layouts used to be a barrier, and “with AI this is no longer a barrier.” I wrote about what those two models are actually good at in Gemini 4 Argon in real work and the GPT-6 Sol vs Astra shootout. Finding memory bugs in a C codebase at scale is a different job from writing marketing copy, and it is the one that just changed the threat model.

How did AI change the attack timeline?

AI shrank the gap between “a fix exists” and “attackers are using it” from days to hours, and in this case to negative hours. Fastly saw PHP2Shell-branded scanning tools more than nine hours before the coordinated release. Sansec expected mass attacks within 15 minutes of the patch. Defenders who planned to patch “this week” were already late.

The detail from Fastly’s analysis that reframed it for me: by release time at 14:00 UTC, more than 100 source IPs had used PHP2Shell-named tooling under more than two dozen tool names. By midday October 22, Fastly had stored about 250,000 such requests from roughly 3,200 IPs.

Why so early? The disclosure leaked. CVE IDs circulated on October 20, a proof-of-concept video went up by mistake and came down, and Chainguard shipped fixed images about six hours before the official release, which the PHP Foundation said broke the embargo. Once a patch is public, a model can read the diff and point at the bug. That is the new part. Patch diffing used to need a skilled human and a few days.

What we still do not know

One honest limitation on all of this: scanning is not compromise. SANS reported that as of October 23 the PHP Foundation knew of no successful exploitation, CISA said on October 21 it had not observed any, and much of the circulating proof-of-concept code did not achieve code execution. Fastly notes that a failed and a successful exploit can look identical at the edge, so only origin logs settle it. The real breach count may take months to surface.

Why did governments tell sites to go offline?

Because for a pre-authentication code execution bug with live scanning, an unpatched public server is not a risk, it is a timer. The NSA recommended that sites which could not update immediately go offline, per TechCrunch. SANS and the Internet Storm Center said the same, and advised assuming compromise for unmitigated public sites.

People followed it. Wikimedia pulled supporting services, the Internet Archive briefly shut down, and in Europe, advice from CERT-EU and the UK NCSC took government portals offline, including the Dutch DigiD login service, according to ExoBrain’s response guide.

This is the part most founders skip past. “Take it offline” is only an option if you have decided, before the incident, who is allowed to make that call for each site and what it costs. On a client site, that is a phone call you do not want to be improvising at midnight.

Is this really AI vs AI cybersecurity?

Half of it is. Attackers are clearly using AI: Microsoft says Storm-0940 used the ARTEX agent framework to automate scanning and password spraying, and the Cairn attacker reportedly broke into more than 100 companies for a few thousand dollars in model costs. But the defense that held in Black October was mostly not AI. It was patch speed and inventory.

The default take right now goes like this: AI attackers can only be stopped by AI defenders, so the answer is a smarter security product. I think that gets the bottleneck wrong for anyone smaller than a bank.

Where AI actually helps defenders

Look at where defenders actually struggled. Fastly found that about a third of the PHP2Shell-named traffic was defensive scanning, and that two older, look-alike campaigns (React2Shell and wp2shell) matched the circulating signatures far more often than PHP2Shell did. In one measured hour, 98.6% and 99.9% of matches for two popular signatures were React2Shell. That is a triage problem, and AI is genuinely good at triage. Separating 250,000 requests into “real” and “noise” is exactly the work I would hand a model.

Where even the experts misread the signal

Even the experts tripped on attribution. Unit 42 linked an intrusion at a European government agency, with agentic AI follow-up activity, to PHP2Shell on October 23, then retracted that link on October 25 because it could not confirm the initial access. If a top threat team can misread the signal in a week like this, a small business owner reading headlines certainly will.

The call I would make

So here is the call. AI helps at the triage layer. The decisive layer is older and less exciting: do you know every place PHP runs, can you patch it inside a day, and can you take it offline without a meeting? I would be wrong about this if defensive AI starts patching and rebuilding production systems on its own, safely. Nothing in Black October showed that yet.

What actually separated the teams that coped?

Three boring capabilities: a current inventory of where PHP runs (including appliances and admin panels), people who can patch within a day, and a record of which secrets each server holds. Anthropic’s deputy CISO Jason Clinton advised leaders to ask the board for support “for the basics.” Those basics decided who was exposed.

The numbers show how rare that is. Censys counted about 7.9 million services moving to fixed PHP versions after October 21, while about 33.5 million still showed affected versions, per ExoBrain. D3 Security cites a Modat finding that 79% of version-readable PHP services run on branches with no official fix.

Why PHP is so hard to inventory

PHP hides. SANS editor Adrian Sanabria listed router and appliance web interfaces, captive portals, webmail, hosting panels, OpenEMR, Moodle and CRM software as affected surfaces, and pointed out that a 2024 PHP bug is still used by malware two years on. In my own work, the forgotten system is never the main site. It is the staging copy from two years ago, the old landing page on a cheap host, or the admin panel nobody remembers is public.

There is a systems idea underneath this. John Boyd’s OODA loop says the side that observes, orients, decides and acts faster wins. Greg Brockman used exactly that framing for defenders. But you cannot observe what you have not inventoried, and you cannot act on a server nobody owns. AI speeds up the decide step. It does nothing for an observe step you never built.

What should you do this week if you run PHP sites?

Patch first, then assume the worst about the window before you patched. Upgrade to a fixed version, restart workers, rebuild images, then hunt back to October 17 and rotate any secret an exposed server could read. A WAF rule is a stopgap, not a fix.

1. Patch. Move to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your OS vendor’s patched package. Restart PHP-FPM workers and rebuild container images, or the old binary keeps running.
2. Find the PHP you forgot. Staging sites, old client sites, hosting panels, appliance admin pages. If you are on 8.1 or older there is no official build, so upgrade or get a vendor backport.
3. Hunt from October 17, not October 21. Amazon saw exploitation attempts in its honeypots from that date. Look for multipart requests followed by memory-limit errors or bursts of HTTP 500s, oversized PHPSESSID cookies, unexplained worker restarts, and PHP spawning shells or making outbound connections.
4. Rotate secrets. Memory disclosure means database passwords, API keys and tokens on that server may be gone. Rotate them at the source.
5. Decide the offline rule now. Write down who can take each site down and under what condition. The next one will not wait for a meeting.
6. Ask hosts and vendors for patch dates in writing. SANS editors flagged that some appliance vendors had not shipped fixes days later.

What breaks next for people building with AI?

The next target is the AI tooling itself. The poisoned LiteLLM 1.107.0 release sat on PyPI for under two hours on October 21 and shipped an infostealer. An AI gateway concentrates every model provider key in one place, which makes it the most valuable box in an agent stack.

This one is closer to home than PHP. Every agent system I build has a place where keys live, and most of them pull packages unpinned during development. The SANS guidance was blunt: if you installed 1.107.0, used an unpinned version, or ran an affected Docker image, assume compromise, pin to 1.106.2 and rotate keys. If you run always-on agents, each one holding credentials is now part of your attack surface, not just your product.

The pattern underneath Black October

Clinton’s prediction, quoted by ExoBrain, is that things “are going to get a lot worse before they get better,” and that security leaders should expect about 18 months of this. OpenAI has said it expects findings like PHP2Shell to increase sharply. I take that seriously, because the same models I use to ship faster are the ones reading patch diffs.

The bigger pattern is not AI vs AI. It is that AI collapsed the time between a weakness existing and someone using it, and every organization’s response speed is now its real security level. The teams that came through Black October were not the ones with the smartest tools. They were the ones that already knew what they owned. If you do one thing this week, write that list.

Frequently asked questions

What is PHP2Shell?

PHP2Shell is the name Wiz gave to two critical memory-safety flaws in the core PHP engine, CVE-2026-109618 and CVE-2026-109619. Chained or used alone, they allow unauthenticated remote code execution and memory disclosure. Both were rated CVSS 9.2 by PHP and were found with help from AI models.

Why is it called Black October?

Black October is the label the security press and practitioners gave October 2026 after a cluster of incidents landed in the same week: PHP2Shell, the poisoned LiteLLM 1.107.0 release, weak eMudhra certificate authority keys and a critical GitLab fix. No single person is credited with coining it.

Which PHP versions fix PHP2Shell?

Upgrade to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your operating system vendor’s patched package. Restart PHP workers and rebuild container images afterwards. PHP 8.1 and older are end of life, so plan an upgrade or use a vendor backport rather than waiting for an official build.

Should I take my website offline if I cannot patch PHP?

If the site is internet-facing, unpatched and has no compensating control, yes. The NSA, SANS and the Internet Storm Center all pointed to taking unpatchable sites offline. A WAF rule or disabling session upload progress buys time against specific paths but does not make the installation safe.

Is AI vs AI cybersecurity real?

Partly. Both PHP2Shell flaws were found with AI help, and attackers are using agent frameworks to automate scanning and exploitation. But most of the damage control in Black October came from patch speed and asset inventory, not from defensive AI. AI is most useful to defenders at triage, sorting real attacks from noise.