the 90 day disclosure policy is dead

The article argues that the traditional 90-day responsible disclosure window for security vulnerabilities is obsolete because large language models (LLMs) have drastically accelerated both bug discovery and exploit development. The author supports this claim with a real-world example where 11 independent researchers reported the same critical bug within six weeks, suggesting that attackers can now find and weaponize vulnerabilities faster than vendors can patch them. The article calls for the industry to treat all critical security issues as immediate "P0" priorities that must be patched instantly, rather than waiting for standard disclosure timelines.

the 90 day disclosure policy is dead Table of Contents TLDR⌗ The 90 day responsible disclosure window was built for a world where bug finders were rare and exploit development was slow. That world is gone. LLMs have compressed both timelines to near-zero. I have seen it first hand, and so has everyone else paying attention. This post lays out why the old model is broken, with real stories, and makes one ask to the industry: treat every critical security issue as P0 and patch it immediately. Not tomorrow. Not next sprint. Now. I have been doing security work for a while now, and the last 12 months feel different. Not in a “AI is going to take over the world” way. In a much more boring, much more practical way. The tools we use, the tools attackers use, and the tools researchers use to find bugs have all gotten smarter at roughly the same speed. And that has quietly killed some of the fundamental assumptions the security industry has been running on for over a decade. Let me walk you through what I mean, with stories. the old world rest in peace ⌗ Pretend it is 2019. You find a critical bug. You write up a report. You send it to the vendor. The vendor takes a few days to triage, a couple of weeks to fix, maybe a month to roll out. If you follow Google Project Zero style disclosure, you give them 90 days before going public. During those 90 days, you assume: - You are probably the only person who found this bug - Even if someone else finds it, they will take their own time - The vendor has a comfortable head start on writing the patch - After the patch lands, attackers need days or weeks to reverse engineer it into a working exploit Every single one of these assumptions is now wrong. story 1: 10 people, 1 bug, 6 weeks⌗ In late April, I reported a pretty bad bug to a company. I am keeping the details vague because the issue is still not patched, but the shape of it goes like this: an attacker can buy anything from the website, send back their own crafted response to the server, and because there is no signature verification on the response, the server happily accepts it. Buy a $5000 item for $0. Mark your purchase as completed without paying. Critical, easy to exploit, very bad day for the company. Cool. I write it up, I send it in, I feel good about myself for about 10 minutes. Then the triage team comes back and says “yeah we know, first reported in March. You are reporter number eleven.” Eleven Freaking people found the same critical bug in roughly six weeks. A friend from BlueWater CTF had flagged this pattern months ago, that LLM-assisted hunters were converging on the same bugs almost simultaneously, across totally unrelated reporters using totally unrelated workflows. And it is not just me noticing this. @d0rsky, who works on the triage side, posted this: “Once a new vulnerability is discovered - especially via some LLM prompt/skills/automation, we start getting a wave of duplicate reports within days. Same root cause, slightly different wording. … What concerns me more, is, if researchers can replicate these findings so quickly, what’s stopping blackhats from doing the same before the issue is fixed? Feels like the window between ‘first discovery’ and ‘mass awareness’ is getting dangerously short.” Exactly. The triage teams are seeing it too. This is not a researcher’s paranoia. It is a pattern. At first I thought, okay, same tools, same prompts, makes sense. But then I did the uncomfortable math. If 10 people reported the bug, how many found it and did not report it? The same LLM that helped 10 honest researchers is also available to everyone else. It does not check your intentions at the door. Out of those 10 reporters, only 1 gets the CVE credit. Only 1 gets the bounty. What about the other 9? How many get frustrated? How many decide to sell it instead of wait? And the people who never reported it at all they are not sitting on a 90 day clock. They are not sitting on any clock. The 90 day window is not protecting users. It is giving everyone who already has the bug a 90 day head start. story 2: 30 minutes from patch to exploit⌗ Recently, React patched a bunch of security issues CVE-2026-23870, CVE-2026-44575, CVE-2026-44579, CVE-2026-44574, CVE-2026-44578 and wrote a public blog post about it. Standard practice. Show your work, explain the fix, give the community a heads up. I read the post out of curiosity. Then I thought, let me see how hard it would be to turn this patch into a working exploit. Just an experiment, on my own machine, against a local test app. 30 minutes. From reading the patch to having a working exploit DOS, as it was DoS only . AI did most of the heavy lifting: understanding the diff, identifying the vulnerable code path, writing the PoC. The published issue was a denial of service, but the underlying primitive could go further with more work. In the old world, turning a public patch into a working exploit n-day exploitation took skilled reverse engineers days to weeks. That gap was the safety net. “We shipped the patch, admins have a few days to update.” That safety net is gone. The gap is now measured in minutes for simple bugs, maybe hours for complex ones. The skilled reverse engineer is optional. The LLM does the boring parts and the human just steers. The moment a patch ships, assume the exploit exists. There is no grace period. Companies cannot afford to “schedule” patch deployment for the next maintenance window. The maintenance window is now. story 3: the week linux caught fire⌗ If you want the clearest possible proof that the 90 day disclosure model is dead, look at the last two weeks of the Linux kernel. Two back-to-back critical vulnerabilities. Both with public exploits. Both affecting every major distribution. The timeline reads like a horror movie. act 1: copy fail⌗ On April 29, Xint Code the team behind Theori, nine-time DEF CON CTF champions publicly disclosed Copy Fail CVE-2026-31431. A straight-line logic flaw in the kernel crypto subsystem. No race condition needed. 100% reliable. A 732-byte Python script that gives you root on every single Linux distribution shipped since 2017. Every. Single. One. Ubuntu, RHEL, Amazon Linux, SUSE, all of them. One curl | python3 && su away from game over. The terrifying detail: they found it using an AI-assisted workflow at unprecedented speed. The discovery didn’t come from blindly running a scanner, but began with a human insight. Theori researcher Taeyang Lee was studying how the Linux crypto subsystem interacts with page-cache-backed data. Once he had that initial thread, he used Xint Code to scale his research across the entire crypto subsystem. What would normally take weeks of manual code auditing took about an hour of AI-assisted scaling. One researcher’s insight. One hour of AI amplification. Nine years of exposure. For the full technical breakdown, read Xint’s writeup. Copy Fail did get a patch mainline commit a664bf3d603d and a straightforward mitigation: disable the algif aead module. People started patching. Deep breath. Okay. Maybe we can handle this. Then threat actors showed up. Iranian adversaries were observed leveraging the vulnerability to compromise Ubuntu servers and repurpose them as nodes for DDoS campaigns. A kernel privilege escalation found by AI, disclosed publicly, weaponized by nation-state actors, used to build attack infrastructure. All within days. act 2: dirty frag⌗ Barely one week later, on May 7, researcher Hyunwoo Kim @v4bel published Dirty Frag CVE-2026-43284 and CVE-2026-43500. Two chained vulnerabilities in the kernel’s IPSec ESP esp4 /esp6 and RxRPC networking modules. Same bug class as Copy Fail and Dirty Pipe. Same page-cache corruption technique. Different attack path. The critical part: Dirty Frag works even if you applied the Copy Fail mitigation. Even if you blacklisted algif aead . Dirty Frag does not use that module. It takes a completely different route to the same result: unprivileged user to root, deterministically, on every major distro. Ubuntu, RHEL 10.1, openSUSE, CentOS Stream, AlmaLinux, Fedora 44. A one-liner to compile and run. And here is where the disclosure model completely fell apart. Hyunwoo Kim reported to email protected on April 29-30. He submitted patches publicly. He coordinated with the linux-distros mailing list on May 7, with a 5-day embargo agreed upon. On that same day within hours an unrelated third party published detailed exploit information for the ESP vulnerability, breaking the embargo. After consulting with the distro maintainers, Hyunwoo published the full Dirty Frag writeup, exploit code, and a working PoC. At that moment, zero Linux distributions had a patch available. As of today, only CVE-2026-43284 the ESP side has a mainline fix. CVE-2026-43500 the RxRPC component still has no upstream patch. And the chained exploit that combines both works on basically everything. Ubuntu, Red Hat, and others have published their own advisories. Microsoft’s Defender team confirmed limited in-the-wild exploitation within 24 hours of disclosure. Attackers gaining SSH access, deploying an ELF binary, popping root via su , modifying authentication configs, wiping session files, moving laterally. The full playbook, live, in production environments. CTS @gf 256 summed it up in five words: “responsible disclosure is dead🤦” https://x.com/gf 256/status/2052480591489122747 Yeah. so what is actually dead here⌗ Let me be specific about what I think is broken beyond repair. The 90 day disclosure window is dead. Not “needs reform”. Not “could use some tweaking”. Dead. It was designed for a world where finders were rare and exploit development was slow. LLMs have made finders abundant and exploit development fast. When 10 unrelated researchers find the same bug in 6 weeks, and AI can turn a patch diff into a working exploit in 30 minutes, what exactly is the 90 day window protecting? Nobody. It is protecting nobody. It is just exposure with a polite name. Copy Fail went from AI scan to public PoC to nation-state weaponization in days. Dirty Frag’s embargo was broken within hours by a third party who independently found the same bug class. You cannot coordinate disclosure when the same vulnerability is being independently rediscovered by multiple researchers and AI tools at the same time. The information does not stay contained anymore. It has LLM-powered legs. Monthly patch cycles are dead too. A 30 day window between vulnerability and fix assumes attackers are slower than your release train. They are not. They have been faster for a while now, and the gap is only widening. Microsoft saw Dirty Frag in the wild within 24 hours. Your monthly maintenance window is not a safety margin. It is an attack window. “Wait for the advisory” is dead. If you are reading CVE descriptions while attackers are reading git log --diff-filter=M , you are already behind. The advisory is a downstream artifact. The patch diff is the signal. what the industry needs to do and I am not sugarcoating this ⌗ I have one ask. One. And I know it sounds extreme. I know it is a lot. But everything I have shown you above points to the same conclusion: Treat every critical security issue as P0 and fix it immediately. Not “within 24 hours”. Not “in the next sprint”. Not “after we assess impact”. Now. As in, stop what you are doing and fix it now. I know that sounds unreasonable. I know production deployments are complicated. I know change management exists for good reasons. But the threat landscape does not care about your change management process. Here is what “immediately” actually looks like in practice: If you are a vendor receiving a critical bug report, your clock starts the moment the report lands. Not when you finish triaging. Not when engineering picks it up. The moment it lands. Because if someone reported it to you, assume 10 other people have it and at least one of them is not friendly. If you are a researcher, stop sitting on cr