Breathe. It’s been a tough week or so for security and dev teams everywhere. You’re not alone.
The disclosures hit hard, but they didn’t come out of nowhere. In August, Anthropic’s Deputy CISO Jason Clinton said a vulnerability tsunami was coming within months. And lo and behold, come October, we had PHP2Shell, two critical remote code execution flaws in PHP, and HTTP2Shell, a flaw in the Brotli compression library (Broccoli2Shell?!). The forecast turned out to be right.
People are calling it Black October, a name that seems to oversell the damage so far, with no mass compromise yet reported. But Clinton now says things will get a lot worse before they get better, and that we need to hold on for about 18 months (whatever that means).
Buckle up.
Cloudflare’s CEO Matthew Prince has a similar forecast. He thinks “we’re going to have a couple years where every single week it’s going to feel like the sky is falling.” Not exactly music to a security pros ears, but we think there should be more optimism and that defenders will come out ahead in the long run, which we’ll get on to.
Why it gets worse before it gets better
Clinton had warned that there won’t be enough time to patch critical infrastructure. His advice was to go to your board and ask for help with the basics, which he said wasn’t about AI. Those basics, as we described in our coverage of the similarly overblown Mythos doomerism, are effectively to know what you run and be able to ship a fix quickly.
To see why it gets worse in the meantime, look at how PHP2Shell happened. The out-of-memory bug behind it had turned up in a 2024 audit and stayed unfixed, because nobody had shown it could be exploited. Last year, researchers did.
“It’s a giant leap to go from ‘I’ve got some weird unexpected behavior, maybe it crashes a worker momentarily’ to what ended up happening, which is unauthenticated remote code execution,” says Mackenzie Jackson, Field CTO at Aikido.
“The role AI played was taking this primitive and turning it into a full-blown proof of concept for remote code execution.”
That kind of unexplained behavior lives in the languages, runtimes and libraries most software is built on, PHP and Brotli among them. Until now, nobody has had time to investigate these. AI can now reduce the effort to do so, working out which of these behaviors leads to a real exploit. It’s a combination of speed, persistence, and the ability to chain flaws together that makes AI so useful for attackers.
Why defenders come out ahead
Ever since Mythos hit the security agenda, security teams have been told to keep increasing the speed and automation of remediation and response. Fixing fast is one of the best ways to defend yourself. But that’s just part of the equation.
This week Anton Chuvakin, former security advisor at Google, argued that defenders should refuse the speed race and focus on invariants: rules the system enforces no matter what. Cybersecurity expert Phil Venables replied:
“+1000 that if your only answer to fast attackers is fast reactive defense then you’re dead. Invariants (aka strong defensive security architecture consistently applied) is vital. But there’s a place for high speed response as well.”
Both have a point. Good architecture limits the damage when a flaw is exploited, but it can’t remove the flaw. Last week’s flaws were in PHP and Brotli, so a team with flawless architecture of its own still had them in its stack. That’s where a faster response to fixing is more critical.
But marrying architecture and fast response is what will put security teams ahead. Everyone talks about “defenders using the same models as attackers” to do this, and this is part of the solution. But it’s how you embed AI into the software development lifecycle that makes the difference.
In practice, the work starts with visibility. You can only fix what you can see, and PHP turned up in places teams didn’t expect, like container base images, CI images, hosting panels and vendor software. Knowing what you run, including what you didn’t install, is what tells you quickly whether a disclosure affects you.
From there, the aim is to build security in earlier and keep fixes quick. That means checking code as it’s written, pentesting your application and your external network with AI before release and again whenever something changes, and getting each finding to a fix a person can review. When there’s no upgrade yet, or an upgrade would break things, stay on the version you run and get the fix added to it. Teams that do this have less to fix when the next disclosure arrives, and what they do have to fix goes out sooner.
Defenders also hold something attackers lack, which is knowledge of the security they have in place.
“People always say the defender has to be always right, but the attacker only has to be right one time. And that makes it very hard to be a defender. It’s not entirely true. The attackers essentially don’t always know about your multiple layers of defenses and the way that you do defense in depth,” Willem Delbare, CEO of Aikido, said about the vulnerabilities last week.
“I think the defenders still have the advantage at the moment. You do have to put in the work, of course,” he continued.
The day after tomorrow
“We're certainly capable of surviving this one. All depends on whether or not we're able to learn from our mistakes”. - Jack Hall, The Day After Tomorrow.
The short-term may be rough, but we think defenders will come out ahead anyway. Fixes have been released for supported PHP versions, many of the sites that needed to go offline did, and no mass compromise has been confirmed (yet). Every team should know where it’s slow and where it has gaps, and the ones that fix those will come out ahead.
