On October 21, the PHP project shipped emergency fixes for CVE-2026-109618 and CVE-2026-109619, two flaws that let an unauthenticated attacker run code on a web server. Both were found with the help of AI models. Cloudflare reported exploit attempts jumping from thousands to millions within hours of disclosure, and by Thursday security people on X had a name for the month: Black October. Former CISA Director Chris Krebs told CNBC that 3% of all critical vulnerabilities ever discovered had turned up in the previous month alone.
PHP runs on a large share of the web, so the scramble was real. But if you treat this as one bad patch cycle, you miss why it happened and why it will happen again.
Finding bugs used to be the slow part
Until recently, a serious vulnerability cost a lot to find. You needed an experienced researcher, weeks with the code and a fair amount of luck. That cost quietly limited how many critical bugs reached the public each month, and vendors and IT teams built their patch routines around that pace.
AI models have taken much of the cost away. A model can read a large codebase, follow how user input moves through it and point to the places where it reaches something dangerous. Microsoft's October Patch Tuesday covered a record 1,413 CVEs, and the one exploited zero-day in that release, a Mark of the Web bypass in Windows Shell, was reportedly uncovered by an AI model. Dark Reading has started calling this period the "vulnpocalypse era."
Defenders benefit when bugs are reported before criminals stumble on them. Attackers have access to similar tools, though, and they only need one server that didn't get patched.
There is no quiet period after a patch anymore
Security teams used to count on a gap between disclosure and mass exploitation, often several days, which was enough to test a fix and schedule a rollout.
That gap has mostly closed. Once a patch is public, an attacker can compare the old and new code, see what changed and work backwards to an exploit. AI makes that step faster as well. The Cloudflare figures on PHP2Shell show the result: scanning started almost as soon as the advisory went out.
When everything is critical, severity scores stop helping
A team receiving 20 critical advisories a month can read each one carefully. At 200 a month, it can't, and a CVSS score of 9.8 tells you little when half the queue scores 9 or higher.
Exploitation data is more useful. CISA's Known Exploited Vulnerabilities catalog lists bugs confirmed as attacked in the wild. EPSS estimates how likely a bug is to be exploited soon, and the PHP flaws sat around the 99.997th percentile. A practical order of work is to start with what faces the internet, then what is already being exploited, then what would do the most damage if compromised.
The hard part is now human judgment
Tools can find and rank vulnerabilities. They can't decide whether to take a customer-facing system offline at 2 a.m., and they won't always notice that strange outbound traffic from a web server means the patch arrived a day late.
People get good at those decisions by making them before they count. A team that has never worked through a "critical RCE was disclosed this morning" scenario will spend the first hours of a real one figuring out who owns which servers. We covered this in If AI Can Hack, How Should We Train Defenders? and in our piece on how cybersecurity drills prepare teams for real attacks. This month gave both arguments some fresh evidence.
Exercises worth running this quarter
These map closely to what happened in October:
- Rapid triage. Give a team 30 new advisories and an asset inventory, then 30 minutes to decide what gets patched today. Score them on whether they caught the exposed, actively exploited items.
- Patch diffing. Show analysts a vulnerable function before and after the fix and ask them to explain the bug. Attackers do exactly this the morning a patch ships.
- Detection after a late patch. Assume the fix went in too late. Can the team find a web shell, unexpected child processes under the web server or new outbound connections?
- Web exploitation basics. PHP2Shell is a web bug, and people who understand injection and file-write flaws read advisories faster. Our post on how well developers understand the OWASP Top 10 is a reasonable place to start.
A cyber range suits this kind of practice because people can attack and defend real services without going near production. On Simulations Labs you can launch a simulation or CTF built around these scenarios, and Simulations Copilot will suggest matching web exploitation and incident response challenges from the library.
AI-assisted discovery isn't going away, and next month's advisory list probably won't be shorter. It's worth finding out how your team handles a morning like October 21 before the next one arrives. Get started for free and run the triage drill this week.
FAQ
What is Black October?
It's the informal name security practitioners gave October 2026, after AI-assisted research produced a wave of critical vulnerabilities, led by the PHP2Shell flaws, that attackers began exploiting within hours of disclosure.
Why are AI models finding so many vulnerabilities now?
They can read and reason about large amounts of code far faster than a human researcher, which lowers the cost of finding serious bugs. More bugs get found, and more get published at once.
How should teams prioritize when there are too many critical patches?
Start with internet-facing systems, then anything listed in CISA's KEV catalog or carrying a high EPSS score, then the assets that would cause the most damage if compromised. CVSS alone isn't enough when most advisories score critical.
Can training really help when the problem is volume?
Yes. Volume is handled by process and judgment, and both improve with rehearsal. Teams that have practiced triage and post-exploitation detection respond faster and make fewer costly mistakes.
