Black October? What PHP2Shell Tells Us About the Future of Vulnerabilities

Introduction

October was a busy month for AI and security, with the story that got the most attention being PHP2Shell. On 20th October the PHP security team announced an out-of-cycle release for two critical remote code execution flaws in the PHP interpreter (CVE-2026-109618 and CVE-2026-109619), affecting every version of PHP, from 5.4 through 8.5.

This article will summarise what happened, why it was called "Black October", and how much of it is actually "new". Security teams deal with critical vulnerabilities all the time, every day, so it's interesting to see what (if anything) was different this time.

What Was Black October?

For starters, "Black October" is just a label picked up by the news to describe the global response to PHP2Shell and the run of AI-discovered vulnerabilities across the month. A key statement throughout October was from Chris Krebs, who said that "3% of all critical vulnerabilities ever discovered have been found in the last month".

The PHP vulnerabilities were no joke though, affecting around 70% of websites (whose server-side language is known), with details of the vulnerabilities leaking shortly before the planned disclosure, resulting in a rapid wave of mass exploitation. Very much a nostalgic event for anyone who worked in security through Heartbleed or Log4Shell.

An interesting aspect of these vulnerabilities was that, typically, finding a critical bug in something as mature as the PHP interpreter has historically been a very slow process that relied on a small number of people with the right skillsets. Naturally this limited how often these types of events happened over the years and gave plenty of time for organisations to plan and patch. This time it was quite different though. PHP2Shell was found using AI, and it was uncovered alongside a large number of other AI-identified critical issues throughout the month, compounding the impact and stress on security teams.

And unfortunately, due to the double-edged sword that is AI, we should expect similar findings to increase quite drastically over the coming months and years. So, although neither the vulnerability class nor the response is new, the scale and response time is, so we should all expect and prepare to go through these types of events a lot more often.

PHP2Shell Cause and Impact

The vulnerabilities were found independently in August 2026 by Ryan Austin at Calif and Wiz. Ryan found them during an audit of PHP's source code as part of OpenAI's "Patch the Planet" effort using GPT-5.6 Sol, whilst Wiz found them using Gemini 4 Argon, GPT-5.6 Sol and its own tooling. Both teams then used the AI to build working exploits and claimed they would likely not have been found without the aid of AI.

From a technical perspective, both vulnerabilities are network accessible, pre-auth, memory management flaws in the PHP core interpreter. Because the bugs are in the actual PHP interpreter, updating higher-level frameworks like WordPress, Magento or Drupal does nothing on its own, so waiting on an update from the PHP core team is necessary for any type of resolution.

Ironically, one of the underlying issues had reportedly been identified by a PHP core developer in 2024 but was never fixed, as the team couldn't agree on an approach and nobody had shown it was exploitable. Now in 2026, the power of AI-assisted research is what ultimately demonstrated that it was.

However, vulnerabilities are identified and remediated all the time, so as is typical a plan was made to coordinate a security update release on 22nd October. However, details leaked via The Hacker News two days earlier, and public PoC exploits were spreading around the internet 12 hours before PHP shipped the expedited patches on 21st October.

Even more interestingly, Amazon had recorded an exploitation attempt in its honeypots on 17th October, four days before disclosure and whilst the bugs were still under embargo, noting that "it remains unclear how the actor acquired exploit information prior to disclosure". Whether these early exploit attempts and disclosures came from a legitimate leak or from someone else finding the same bug with the same kind of AI tooling remains unclear.

According to Cloudflare, thousands of exploitation attempts were observed in the 10 hours before public disclosure, tens of thousands within 45 minutes of it, hundreds of thousands within two hours, and millions as of the time of writing. A European government entity was reportedly compromised within two hours, and Mirai botnet operators were quick to add the exploits to their arsenal. Palo Alto Networks also confirmed that PAN-OS and several of its network products were affected, which is a pretty good reminder that PHP is often bundled inside appliances and software that may not typically be seen as "PHP applications".

It should be noted, however, that much of the traffic Cloudflare and others recorded was scanning and exploitation attempts, rather than confirmed compromises, with few fully successful attacks. The more visible impact came as services took themselves offline. Following guidance from CERT-EU, the UK NCSC and the Canadian Centre for Cyber Security, government services in several European countries and Canada were taken down as a precaution, and the NSA recommended that sites go offline if they couldn't update immediately.

The Economic Shift

One of the biggest changes to the vulnerability management ecosystem in the age of AI is that the cost of finding a critical issue in a mature, heavily scrutinised codebase has dropped significantly. In the PHP2Shell example, we can see clearly that two separate teams found the exact same issues, in the same product, in the same month, using commercially available frontier models. And on top of that, with OpenAI putting $1 billion of subsidised access behind its "Daybreak for Frontline Defenders" programme, it's looking pretty promising, as these types of issues being discovered may have been sitting around for decades.

However! Fixing the issues… now that hasn't got cheaper in the same way. According to The Guardian, the PHP Foundation has 13 full-time and part-time employees responsible for the interpreter that runs most of the websites on the internet, and every AI-uncovered critical vulnerability still needs a real-life human maintainer to understand it, agree on a fix, test it across supported branches, coordinate disclosure, and push it out.

Exploit development, meanwhile, has become even cheaper. As Amazon noted, "AI-assisted analysis makes it cheaper to turn a patch diff or advisory into a working exploit", and when patched builds are shipped early, the difference effectively becomes an exploit recipe.

So, now, all in all, finding bugs is cheap, and weaponising them is cheap... but fixing and deploying fixes is still pretty slow, expensive, and dependent on small teams of people.

This imbalance is the part of "Black October" I think is most worth paying attention to, as it's not something a single coordinated disclosure can solve, regardless of how well run it might be.

Business as Usual?

So, was "Black October" some groundbreaking event or nothing new?

Well, for most security teams, being alerted to a critical vulnerability and managing an emergency patch is just a normal day. Especially with tens of thousands of CVEs published every year and vulnerability management programmes built specifically to deal with them. So, in that regard, PHP2Shell was handled the same way these events usually are: advisories went out, vendors shipped updates and WAF rules, and teams patched what they could and isolated what they couldn't.

The difference is that most of those processes assume there is at least some window between a fix being released and widespread exploitation, and with PHP2Shell that window didn't really exist. This left security teams in a bit more of a unique situation, where they may know for a fact that they are vulnerable, but also that the published mitigations were incomplete, leaving them to decide whether a temporary mitigation is good enough, or whether exposed systems simply needed to be taken offline. And massive decisions like that often need to be made within hours, without a clear picture of where PHP is actually running in your estate.

So, in practice, being ready for the next "Black October" comes down to a few things:

• Know what you run, including the appliances and control panels that bundle specific technologies (like PHP), so the "are we exposed?" question can be answered in minutes rather than hours or days.
• Integrate emergency patching, and the decision to take core services offline, into your disaster recovery plans, and ensure they are rehearsed processes rather than improvised ones.
• Layer compensating controls, such as restricting outbound traffic from web servers and having active monitoring to alert if web server processes start spawning shells.
• Use AI capabilities defensively, running checks against your own codebases and patch diffs, as attackers are already doing the equivalent.

All in all, I'd describe PHP2Shell as "mostly business as usual" but with a few exceptionally bad days.

Conclusion

Black October is a catchy name for a very familiar type of event. Critical vulnerabilities in widely used software have always turned up, and security teams have always had to respond to them. What made PHP2Shell different was that it was found independently by two teams using AI, and exploited before a fix was available, whilst the core processes that depend on people (triage, fixing, packaging, deployment) haven't got any faster. But the silver lining is that AI found these bugs, and a decade-old flaw has now been patched.

However, if the current rate of discovery continues, investment can't simply focus on finding vulnerabilities and bugs. It will need to also go into the people and processes that fix them, and into providing organisations with a clear view of what they run, so they can respond quickly.

Most teams can absorb one PHP2Shell, one Heartbleed, one Log4Shell every few years. But the question we should ask now is, can they absorb one or more every month?