Jan Schaumann · Signs of Triviality · October 27, 2026
\nWhat a week,\nhuh? High fives all around—October is\n"Cybersecurity Awareness Month", and I think we've all\ndone a stellar job. If both the New\nYork Times and NPR\nreport on one of the at least four or five concurrent\nfires I'm fighting, then I think we can say that\nyeah, people are aware of cybersecurity. Mission\naccomplished, so... could we maybe turn it down a bit?
\nThe current situation is not sustainable: 0-days are\ndropping left and right, pre-notifications and\nembargoes are broken\nfor marketing purposes, AI companies compete first\non who commits the most crimes and then pretend to\nsell you protection in the form of a DoS on the Open\nSource community. "*Nice project you got there. Be\na shame if somebody dropped an 0-day on\nit."*1
\nCompanies are not staffed for this, and no matter what\nthe industry wants to tell you, you can't AI your way\nout of this. Vulnerability discovery has\nfundamentally changed, disclosure processes are effectively broken, and patch management\nhas been a losing proposition for years now. Severe\nvulnerabilities are identified and disclosed at a pace\nthat defenders are unable to keep up with.
\nThis is because it still takes significant resources\nto accurately assess the feasibility of a given\nvulnerability within your environment; it takes time\nto discover your attack surface relevant to the given\nattack vector, and it takes even more time to deploy a\nfix. As I've said\nbefore, development of the fix is not the\nbottleneck. Let me illustrate with examples from the\nlast couple of days:
\nInitially disclosed as a "KVM escape", this\nvulnerability also applies to other\nvirtualization as well as containers, although that\nangle hasn't really gotten much attention. You now\nneed to assess which possible mitigations might be in\nplace across your fleet of systems, then determine\nwhether you can livepatch\nyour kernels with the custom patches you pull from\nupstream or if you want to wait for your upstream OS\nprovider to deliver a new kernel2 and then all you\nhave to do is reboot a few thousand systems.
\nHow does AI help you here? Maybe you spend a few\nthousand dollars on tokens to use the most advanced\ncyber cyber models to develop your own exploit, but in\nthe end, that doesn't really tell you anything you\ndidn't already know, and your defensive position and\ntasks at hand remain the same.
\nThis one's fun, isn't it? Sure, browsers were all set\nquickly, but guess what, there's a few other\nthings that might use TLS in your environment.\nLike... everything. So again, having the\nfix is not the bottleneck. Waiting for upstream\npackages to release an update only blocks you if you\nactually know that you need to pull in that update.
\nOh, you have a detailed package inventory or, dare I\nsay it, SBOMs? That's really nice. Do show me where\nthat lists the various vendored\nor hard-coded CA trust bundles. Yeah, I didn't\nthink so.3
\n(At least this incident was not AI generated,\ndetected, or triggered. Just one of your wholesome,\nclassical, a-human-going-"huh"\nkind of discoveries. It's almost reassuring that we\nstill get these, too.)
\nThe PHP vulnerability that supposedly affects "over\n70% of websites" (a widely quoted, but never\nattributed statistic) was disclosed under embargo to\nseveral organizations. If you were part of this inner\ncircle, then this should have reduced your panic-mode\nsomewhat, buying you at least some time to\ndeploy protections for your customers and do the\ntedious work of sifting through your inventory and,\nagain, identify the attack surface, affected systems,\npossible local mitigations, etc. etc. The usual.
\nUnless the embargo is broken. Then you get to\nscramble again. And you need to keep up to date with\nall the rapidly published (and increasingly verbosely\nAI polluted) breathless blog posts driven by cyber\nsecurity vendors' marketing teams eager to beat each\nother as the first to detect4, first to exploit, first\nto brag, all of which adds to the distraction.
\nAnd of course you still need to do the actual\nwork of determining the accuracy of the various\nexploits floating around the internet, some put\ntogether by people with a clue and many, many slopped\ntogether by those lacking a full understanding of the\nbug5. (More on that below.)
\nAnd then, by the time Thursday rolls around, people start\nto see a NodeJS\nsecurity advisory, which includes as the third\n"high" severity vulnerability an issue with the\n"Node.js Brotli decoder". Alright, attack surface\nenumeration, software inventory check, start to deploy\nupdated packages,... the usual.
\nExcept, of course, once you take a closer look, it\nbegins to dawn\non you that this goes well beyond just\nNode.js6. And so once again,\nhaving the upstream\nfix available is absolutely not your bottleneck,\nbecause you still need to find the plethora of\nfrankenstances of brotli across all of your\nstacks first.
\nOf course at that point in time OpenAI starts\nto go "Us! It was us! We found it!" even though\nthe issue was\nfixed back in February and Mozilla noted\nthe critical security impact as far back as April.\nIt seems there's no vulnerability, no compromise, no\ncyber crime AI companies are not willing to claim as\ntheir credit.
\nAll of this was going on over the course of one week,\nand doesn't even account for the previous set of\nweekly Linux local privilege escalation\nvulnerabilities7. And no doubt there will\nbe more such disclosures—many more.
\nAI companies are incentivized to continue the\nonslaught, with the most benevolent interpretation of\nmass disclosures of findings being a canonical example\nof "verschlimmbessern",\nwith less friendly interpretations observing that it's\nprofitable for a company to create the disease for\nwhich they're selling you to treatment (and never the\ncure). They've got a new toy, it's a hammer, and by\ngolly they're gonna swing it.
\nMillions of dollars have been spent on identifying\nvulnerabilities using so-called "frontier AI models",\nand we know that adversaries are feeding, e.g., the\nLinux kernel commit messages into their models to\nanalyze them for exploitable vulnerabilities on the\nfly. Today, vulnerabilities are found independently\nby multiple parties on a regular basis, so you already\nhave to assume that a disclosure embargo \nonly contains the massive exploitation\nby opportunistic adversaries at best.
\nAt the same time, I'm observing a worrying trend on\nthe defensive side of cyber security, which mirrors\nthe same de-skilling trend across the industry: AI\ngenerated vulnerability reports are often much, much\ntoo verbose to be digested easily by human readers.\nThey drown you in details, overwhelm your attention\nwith unnecessary information. Because defenders don't\nfully understand the vulnerabilities described here,\nthey tend to believe the generally exaggerated\nseverity claims, and feed the full report into\ntheir AI to reproduce or generate a proof of\nconcept.
\nSeveral thousand tokens later, you end up with a\nbinary handed to you by a meat-proxy that's supposed\nto trigger the vulnerability, but nobody actually\nunderstands why it works. Which, more often than not,\nit actually doesn't, because your environment\nis different, your AI was missing context the\nmeat-proxy didn't (know to) provide, because the code\nbase differs from upstream, or who knows what else.\nWhen you ask for clear instructions on how to run the\nexploit, what pre-conditions need to be met, and how\nit works—you know, the kind of one-pager that\noffensive engineers used to be able to\nproduce—you get back, you guessed it, an\nAI-vomited 7,000 word\nREADME.md.8
Fighting one fire at a time is taxing enough. Each\none of the above examples would have been a\nonce-a-year incident not too long ago. Having\nmultiple such incidents at the same time is burning\nout all your incident response staff, your engineers,\nyour comms and legal teams.
\n(And it always is more or less the same set\nof people driving each incident. I have not seen\norganizations properly staffed and not relying on the\nsame set of ghostbusters—the heroes and company-elders with the\nrequired tribal knowledge to make up for the gaps in\nyour software inventory, attack surface enumeration,\nand documentation, because who else are you gonna\ncall?)
\nContext switching between each of these incidents\nmeans you can't focus on any one of them, making you\nmore likely to miss important information, to fall for\nsensationalistic headlines, to succumb to pressure and\nto rush fixes you don't understand for vulnerabilities\nthat might not apply in your environment. Which, in\nturn, makes more people more susceptible to the\nappealing lure of quick and confident answers from the bot, and\nsubject-matter non-experts start to paste their prompt\nresults into incident response channels.
\nThis is not sutainable.
\nOh, lol, sorry, I mislead you. When you ramble and\nrant, you're supposed to end on an upbeat note,\nprovide a solution9, proffer suggestions on how we can\nall roll up our sleeves and work together and solve\nthe problem. Alas, I have no idea.
\nAh, but surely all of this is just temporary,\nright? AI will find all the vulns, we slog through\nthis dark winter of disclosure chaos, and then come\nout in a world where all software vulnerabilities have\nbeen found and fixed.
\nIf you're able to believe that, I envy you. I don't\nsee it happening. If you try to tell me that software\ndevelopers should just use AI to generate patches,\nremember that over\n50% of the time, AI either doesn't fix the issue,\nintroduces a new vulnerability, or changes the\napplication's behavior in the process. Reducing our\nown understanding of complex software while\nsimultaneously producing\nmore and more code is a recipe for more\nvulnerabilities, not fewer. And, at the risk of\nsounding like a broken record, *getting the\nvulnerability fixed is not the bottleneck*.
\nEven if the current status were temporary—for\nhow long? A year? Two? And what are we supposed to\ndo in the meantime? Hiring more infosec staff isn't\nlikely to happen in\nthis economy. Investing into overhauling your\nentire infrastructure such that you can at least\npull in and deploy updates automatically and reboot your\nfleet and do all that safely is equally\nunlikely: companies have gotten away with not\ndoing that for decades, and who wants to be the VP or\nexecutive who shifts funding away from "moar code moar\nfaster"? Not to mention that such a project would\ntake several years as well.
\nThe last option left is to simply accept the status\nquo. There will be more vulnerabilities, including\nRCEs, and you won't be able to keep up with them.\nYour only option is to limit the blast radius.\nAssume compromise, detect exploitation, limit\nexposure, lateral movement, privilege escalation, etc.\nIf that sounds like an old hat, well, yes, that's what\nsane infosec practitioners have been asking for\nfunding for for decades. (We used to call it "Zero\nTrust", before that became an empty marketing term.)\nBut that funding instead goes to the next singing\nand dancing, AI-based vulnerability management SIEM\ndashboardmajing, which will only miss 40% of your\ninfrastructure and assets. Hooray!
\nWell, good night and good luck, indeed.
\nOctober 27th, 2026
\nFootnotes:
\n[1] The same racket works even better with\nbusinesses: "*Nice supply chain you got there. Be\na shame if somebody dropped hundreds of 0-days for\nmost of your dependencies. Better subscribe to our\nservice to get pre-notification.*"\n↩
\n[2] As of 2026-10-27, 12 days after initial\ndisclosure, Canonical, to name one example, still doesn't\nship a fixed kernel, considering the issue of\n"medium" severity.\n↩
\n[3] Your best bet in some cases is to just run a simple\nfetch using the language/framework in question.\nBut that doesn't scale, either. Good luck, tho!\n↩
\n[4] Detection of exploit attempts is a critical signal\nto help you assess the urgency of your response and\ncan influence disclosure timelines. Announcing\nyou've observed per-disclosure exploitation\nwithout sufficient confidence is\nharmful to all responders.\n↩
\n[5] And don't get me started on using\nsetjmp(3)/longjmp(3) for error handling\nin any even remotely complex program. Sure, it's\nclever, but writing clever is rarely\nthe same as writing safe code. I'm not\nconvinced you can use this mechanism safely in all but\nthe most trivial cases, and wouldn't be surprised if\nadditional vulnerabilities are lurking here. And now\nthat the Eye of Sauron is trained on this codebase...\n↩
[6] By the way, does anybody know why Google Docs\ninsists on hyperlinking node.js?\n.js is not a TLD. Is it really stupid\nenough to just go by\n[a-z0-9.-]+\\.[a-z]{2}? Oh, it totally is.\nBrilliant.\n↩
[7] Disclosures like "Linux\nkernel LPEs: ZcopyReaper (CVE-2026-43502) *and 20\nmore* are pretty much par for the course\nafter we got "DirtyFrag", "GhostLock",\n"FragGap",\n"ZapScape",\n"Januscape",\nand I forgot what else in a constant trickle earlier\nthis year.\n↩
\n[8] Granted, that's only marginally more than some\ndude's ranting all-over-the-place blog post. But at\nleast that was 100% human generated.\n↩
\n[9] I would like to say that one way forward here is\naccountability. To hold companies\naccountable for what they do—including what they\nenable or allow their software, their models, their\nbots to do. That certainly is necessary for the\nvarious reckless AI companies as they continue to fail\nto restrict their malware. I'd also like to hold\nvendors accountable for shipping software with known\nvulnerabilities, but I don't know what that is\nsupposed to work for Open Source, nor do I think it\nsolves the disclosure-as-ddos problem.\n↩
\nOriginally published at netmeister.org.
","headings":[{"level":3,"text":"\"PwnEscape\" (CVE-2026-99999)","id":"pwnescape-cve-2026-99999"},{"level":3,"text":"eMudhra compromise","id":"emudhra-compromise"},{"level":3,"text":"\"php2shell\" (CVE-2026-109618, CVE-2026-109619)","id":"php2shell-cve-2026-109618-cve-2026-109619"},{"level":3,"text":"The brotli RCE (CVE-2026-111497)","id":"the-brotli-rce-cve-2026-111497"},{"level":3,"text":"(More) Winter is Coming","id":"more-winter-is-coming"},{"level":3,"text":"Incident Fog","id":"incident-fog"},{"level":3,"text":"How it gets better","id":"how-it-gets-better"}]}}