This is not sustainable

Companies are not staffed for this, and no matter what the industry wants to tell you, you can't AI your way out of this. Vulnerability discovery has fundamentally changed, disclosure processes are effectively broken, and patch management has been a losing proposition for years now. Severe vulnerabilities are identified and disclosed at a pace that defenders are unable to keep up with.

This is because it still takes significant resources to accurately assess the feasibility of a given vulnerability within your environment; it takes time to discover your attack surface relevant to the given attack vector, and it takes even more time to deploy a fix. As I've said before, development of the fix is not the bottleneck. Let me illustrate with examples from the last couple of days:

"PwnEscape" (CVE-2026-99999)

Initially disclosed as a "KVM escape", this vulnerability also applies to other virtualization as well as containers, although that angle hasn't really gotten much attention. You now need to assess which possible mitigations might be in place across your fleet of systems, then determine whether you can livepatch your kernels with the custom patches you pull from upstream or if you want to wait for your upstream OS provider to deliver a new kernel2 and then all you have to do is reboot a few thousand systems.

How does AI help you here? Maybe you spend a few thousand dollars on tokens to use the most advanced cyber cyber models to develop your own exploit, but in the end, that doesn't really tell you anything you didn't already know, and your defensive position and tasks at hand remain the same.

eMudhra compromise

This one's fun, isn't it? Sure, browsers were all set quickly, but guess what, there's a few other things that might use TLS in your environment. Like... everything. So again, having the fix is not the bottleneck. Waiting for upstream packages to release an update only blocks you if you actually know that you need to pull in that update.

Oh, you have a detailed package inventory or, dare I say it, SBOMs? That's really nice. Do show me where that lists the various vendored or hard-coded CA trust bundles. Yeah, I didn't think so.3

(At least this incident was not AI generated, detected, or triggered. Just one of your wholesome, classical, a-human-going-"huh" kind of discoveries. It's almost reassuring that we still get these, too.)

"php2shell" (CVE-2026-109618, CVE-2026-109619)

The PHP vulnerability that supposedly affects "over 70% of websites" (a widely quoted, but never attributed statistic) was disclosed under embargo to several organizations. If you were part of this inner circle, then this should have reduced your panic-mode somewhat, buying you at least some time to deploy protections for your customers and do the tedious work of sifting through your inventory and, again, identify the attack surface, affected systems, possible local mitigations, etc. etc. The usual.

Unless the embargo is broken. Then you get to scramble again. And you need to keep up to date with all the rapidly published (and increasingly verbosely AI polluted) breathless blog posts driven by cyber security vendors' marketing teams eager to beat each other as the first to detect4, first to exploit, first to brag, all of which adds to the distraction.

And of course you still need to do the actual work of determining the accuracy of the various exploits floating around the internet, some put together by people with a clue and many, many slopped together by those lacking a full understanding of the bug5. (More on that below.)

The brotli RCE (CVE-2026-111497)

And then, by the time Thursday rolls around, people start to see a NodeJS security advisory, which includes as the third "high" severity vulnerability an issue with the "Node.js Brotli decoder". Alright, attack surface enumeration, software inventory check, start to deploy updated packages,... the usual.

Except, of course, once you take a closer look, it begins to dawn on you that this goes well beyond just Node.js6. And so once again, having the upstream fix available is absolutely not your bottleneck, because you still need to find the plethora of frankenstances of brotli across all of your stacks first.

Of course at that point in time OpenAI starts to go "Us! It was us! We found it!" even though the issue was fixed back in February and Mozilla noted the critical security impact as far back as April. It seems there's no vulnerability, no compromise, no cyber crime AI companies are not willing to claim as their credit.

(More) Winter is Coming

All of this was going on over the course of one week, and doesn't even account for the previous set of weekly Linux local privilege escalation vulnerabilities7. And no doubt there will be more such disclosures—many more.

AI companies are incentivized to continue the onslaught, with the most benevolent interpretation of mass disclosures of findings being a canonical example of "verschlimmbessern", with less friendly interpretations observing that it's profitable for a company to create the disease for which they're selling you to treatment (and never the cure). They've got a new toy, it's a hammer, and by golly they're gonna swing it.

Millions of dollars have been spent on identifying vulnerabilities using so-called "frontier AI models", and we know that adversaries are feeding, e.g., the Linux kernel commit messages into their models to analyze them for exploitable vulnerabilities on the fly. Today, vulnerabilities are found independently by multiple parties on a regular basis, so you already have to assume that a disclosure embargo only contains the massive exploitation by opportunistic adversaries at best.

At the same time, I'm observing a worrying trend on the defensive side of cyber security, which mirrors the same de-skilling trend across the industry: AI generated vulnerability reports are often much, much too verbose to be digested easily by human readers. They drown you in details, overwhelm your attention with unnecessary information. Because defenders don't fully understand the vulnerabilities described here, they tend to believe the generally exaggerated severity claims, and feed the full report into their AI to reproduce or generate a proof of concept.

Several thousand tokens later, you end up with a binary handed to you by a meat-proxy that's supposed to trigger the vulnerability, but nobody actually understands why it works. Which, more often than not, it actually doesn't, because your environment is different, your AI was missing context the meat-proxy didn't (know to) provide, because the code base differs from upstream, or who knows what else. When you ask for clear instructions on how to run the exploit, what pre-conditions need to be met, and how it works—you know, the kind of one-pager that offensive engineers used to be able to produce—you get back, you guessed it, an AI-vomited 7,000 word README.md.8

Incident Fog

Fighting one fire at a time is taxing enough. Each one of the above examples would have been a once-a-year incident not too long ago. Having multiple such incidents at the same time is burning out all your incident response staff, your engineers, your comms and legal teams.

(And it always is more or less the same set of people driving each incident. I have not seen organizations properly staffed and not relying on the same set of ghostbusters—the heroes and company-elders with the required tribal knowledge to make up for the gaps in your software inventory, attack surface enumeration, and documentation, because who else are you gonna call?)

Context switching between each of these incidents means you can't focus on any one of them, making you more likely to miss important information, to fall for sensationalistic headlines, to succumb to pressure and to rush fixes you don't understand for vulnerabilities that might not apply in your environment. Which, in turn, makes more people more susceptible to the appealing lure of quick and confident answers from the bot, and subject-matter non-experts start to paste their prompt results into incident response channels.

This is not sutainable.

How it gets better

Oh, lol, sorry, I mislead you. When you ramble and rant, you're supposed to end on an upbeat note, provide a solution9, proffer suggestions on how we can all roll up our sleeves and work together and solve the problem. Alas, I have no idea.

Ah, but surely all of this is just temporary, right? AI will find all the vulns, we slog through this dark winter of disclosure chaos, and then come out in a world where all software vulnerabilities have been found and fixed.

If you're able to believe that, I envy you. I don't see it happening. If you try to tell me that software developers should just use AI to generate patches, remember that over 50% of the time, AI either doesn't fix the issue, introduces a new vulnerability, or changes the application's behavior in the process. Reducing our own understanding of complex software while simultaneously producing more and more code is a recipe for more vulnerabilities, not fewer. And, at the risk of sounding like a broken record, *getting the vulnerability fixed is not the bottleneck*.

Even if the current status were temporary—for how long? A year? Two? And what are we supposed to do in the meantime? Hiring more infosec staff isn't likely to happen in this economy. Investing into overhauling your entire infrastructure such that you can at least pull in and deploy updates automatically and reboot your fleet and do all that safely is equally unlikely: companies have gotten away with not doing that for decades, and who wants to be the VP or executive who shifts funding away from "moar code moar faster"? Not to mention that such a project would take several years as well.

The last option left is to simply accept the status quo. There will be more vulnerabilities, including RCEs, and you won't be able to keep up with them. Your only option is to limit the blast radius. Assume compromise, detect exploitation, limit exposure, lateral movement, privilege escalation, etc. If that sounds like an old hat, well, yes, that's what sane infosec practitioners have been asking for funding for for decades. (We used to call it "Zero Trust", before that became an empty marketing term.) But that funding instead goes to the next singing and dancing, AI-based vulnerability management SIEM dashboardmajing, which will only miss 40% of your infrastructure and assets. Hooray!

Well, good night and good luck, indeed.

October 27th, 2026

---

Footnotes:

[1] The same racket works even better with businesses: "*Nice supply chain you got there. Be a shame if somebody dropped hundreds of 0-days for most of your dependencies. Better subscribe to our service to get pre-notification.*" ↩

[2] As of 2026-10-27, 12 days after initial disclosure, Canonical, to name one example, still doesn't ship a fixed kernel, considering the issue of "medium" severity. ↩

[3] Your best bet in some cases is to just run a simple fetch using the language/framework in question. But that doesn't scale, either. Good luck, tho! ↩

[4] Detection of exploit attempts is a critical signal to help you assess the urgency of your response and can influence disclosure timelines. Announcing you've observed per-disclosure exploitation without sufficient confidence is harmful to all responders. ↩

[5] And don't get me started on using setjmp(3)/longjmp(3) for error handling in any even remotely complex program. Sure, it's clever, but writing clever is rarely the same as writing safe code. I'm not convinced you can use this mechanism safely in all but the most trivial cases, and wouldn't be surprised if additional vulnerabilities are lurking here. And now that the Eye of Sauron is trained on this codebase... ↩

[6] By the way, does anybody know why Google Docs insists on hyperlinking node.js? .js is not a TLD. Is it really stupid enough to just go by [a-z0-9.-]+\.[a-z]{2}? Oh, it totally is. Brilliant. ↩

[7] Disclosures like "Linux kernel LPEs: ZcopyReaper (CVE-2026-43502) *and 20 more* are pretty much par for the course after we got "DirtyFrag", "GhostLock", "FragGap", "ZapScape", "Januscape", and I forgot what else in a constant trickle earlier this year. ↩

[8] Granted, that's only marginally more than some dude's ranting all-over-the-place blog post. But at least that was 100% human generated. ↩

[9] I would like to say that one way forward here is accountability. To hold companies accountable for what they do—including what they enable or allow their software, their models, their bots to do. That certainly is necessary for the various reckless AI companies as they continue to fail to restrict their malware. I'd also like to hold vendors accountable for shipping software with known vulnerabilities, but I don't know what that is supposed to work for Open Source, nor do I think it solves the disclosure-as-ddos problem. ↩

---

Originally published at netmeister.org.