A Linux kernel networking vulnerability called Copy Fail became public in early May 2026 — and the way it unravelled is a clean case study in how AI acceleration is stressing both of the dominant approaches to vulnerability disclosure.

Jeff Kaufman’s analysis of the incident is the sharpest practitioner take I’ve seen on this tension. It’s worth reading in full. This post unpacks the two cultures he describes and what practitioners should take away about the changing disclosure landscape.

Two Cultures, One Kernel

The Linux kernel security world has long operated on a “bugs are bugs” philosophy. When researcher Hyunwoo Kim found the Copy Fail vulnerability, he followed the standard Linux networking procedure: share details with a closed list of Linux security engineers, then push the fix to the public tree quietly and efficiently — without drawing attention to the security nature of the change. The logic is that with thousands of commits flowing past, most people won’t notice, and the people who matter (those maintaining distributions, enterprise kernels, or critical infrastructure) can patch before any attacker understands the significance.

This coexists uneasily with “coordinated disclosure” — the broader practice (more common outside the kernel world) of privately notifying a vendor and giving them 90 days to fix before going public. Here the goal is that no one learns about the hole until a fix is available.

Both approaches aim to give defenders time to patch before attackers can exploit. They differ on how that time is created: the coordinated model uses a formal embargo and a defined timeline; the “bugs are bugs” model uses obscurity and the signal-to-noise ratio of a busy commit stream.

The Copy Fail Break

What happened with Copy Fail illustrates the crack in both models.

Kim reported the vulnerability privately to the Linux security list and also pushed the fix to the public git tree. (Kim’s write-up is titled dirtyfrag; the independent researcher who later publicized it called their analysis Copy Fail 2 / Electric Boogaloo — different names for the same vulnerability family.) Within hours of the fix landing publicly, someone else independently noticed the commit, recognized the security implications, and published a full write-up. The obscurity the fix relied on had failed — and the fix hadn’t had time to propagate to the distributions and deployments that needed it.

Even more striking: just nine hours after Kim privately reported the ESP variant of the vulnerability to the Linux security list, Kuan-Ting Chen independently reported the same thing. The signal the kernel community was relying on — “so many commits that no one will notice” — had failed. The signal-to-noise ratio in the commit stream is no longer low.

How AI Changes the Calculus for “Bugs Are Bugs”

The “bugs are bugs” strategy never worked perfectly. Determined attackers would occasionally notice. But at historical rates of manual code review, the risk was low enough that the operational simplicity of fixing in the open was worth it.

AI changes this in two ways.

First, examining commits has become much cheaper and more effective. Security researchers can now run each kernel commit through a model and ask “does this look like a security fix?” Kaufman ran an informal one-shot test (his caveat: “don’t put much stock in the cross-model comparison”) on three frontier models using the Copy Fail commit: all three identified it as a security patch when given the full commit context. When given only the raw diff, Gemini was confident, GPT thought it was probable, Claude thought it probably wasn’t. This is illustrative, not a controlled benchmark — one run each, no control group — but it captures what’s now within reach of any researcher running automated commit scanning.

Second, the density of security-adjacent commits in open-source projects may be increasing. AI-assisted vulnerability discovery tools can surface vulnerabilities at scale — Anthropic’s recently open-sourced scanning framework found 1,596 potential issues across partner codebases (a figure about discovered issues, not confirmed vulnerabilities or public commits, so treat it as an indicator of scale rather than a direct commit-density measure). If more vulnerabilities are being found and fixed via AI-assisted scanning than before, more security-relevant commits flow through public repositories — which makes automated commit-stream scanning incrementally more rewarding for anyone watching.

The practical result: the “obscurity” the “bugs are bugs” model relied on is eroding. Attackers who run automated scanning on kernel commits will find security fixes faster than they would have two years ago. The window between “fix lands publicly” and “attacker understands the fix” is compressing.

How AI Changes the Calculus for Coordinated Disclosure

Long embargoes face a different problem. The historical basis for a 90-day window was that independently discovering the same vulnerability during that period was unlikely. If you found something and privately reported it, there was a good chance no one else would notice before a fix was out.

That assumption is plausibly eroding. With AI-assisted groups scanning software for vulnerabilities, the probability of parallel independent discovery during a long embargo window is higher than it was — though how much higher is hard to quantify from a single incident. Copy Fail is an illustrative data point, not statistical proof: nine hours from first report to independent second report. One anecdote doesn’t establish a trend, but the underlying mechanics are sound: cheaper, parallel scanning should increase independent discovery rates. The right question isn’t whether this is already happening at scale, but whether the old assumption (low parallel-discovery risk) still holds well enough to justify the risks that come with long embargoes.

Worse, long embargoes can actively increase risk. They create a false sense of non-urgency — once a vendor accepts a report and starts an internal fix cycle, the organizational incentive to move fast can weaken. They also limit which actors can work on mitigation: only the handful of people inside the embargo have the information needed to build compensating controls, deploy mitigations, or prioritize patching.

The Pressure Point: Neither Model Was Designed for This

Both cultures evolved under the assumption that finding a specific vulnerability was slow and hard. “Bugs are bugs” worked because the commit stream was noisy. Coordinated disclosure worked because independent parallel discovery was rare.

AI assistance changes the base rate of finding on both sides — for attackers who scan public repositories and commit feeds, and for defenders who use the same tools. The asymmetry both models relied on (my finding process is fast; the attacker’s finding process is slow) no longer holds at historical embargo lengths.

What Might Work Instead

Kaufman’s tentative conclusion — offered as his personal view, not a policy prescription — is that very short embargoes seem like the best current approximation. The logic: if parallel discovery is now faster, long embargoes offer less protection than they used to while preserving the organizational risks (false sense of non-urgency, restricted defender pool). Shorter embargoes preserve the useful part (time for coordinated patching and communication to key stakeholders) while reducing that window.

How short is appropriate depends heavily on the vulnerability: some require 90 days or more for a safe fix, particularly in hardware, embedded systems, or where wide deployment means patching takes months regardless of disclosure timing. Compression isn’t universally safe. The more defensible version of the argument is that the default assumptions about embargo length deserve reconsideration — not that all embargoes should be shrunk uniformly.

The other side of the ledger: AI can speed up defenders as well. If AI tools can detect vulnerability-fixing commits quickly, they can also accelerate the distribution of mitigation advice, the generation of detection rules, and the prioritization of patching for critical infrastructure. Shorter embargoes can coexist with better tooling for rapid defender response.

Practitioner Implications

For organizations running open-source-based systems: Assume that security-adjacent commits to upstream projects are identified faster than they were two years ago. Your patch-lag window is shorter. Monitoring upstream security advisories is necessary but no longer sufficient — under “bugs are bugs,” security fixes often ship as unremarkable commits with no advisory at all. Monitoring commit streams with automated tooling (or subscribing to services that do) is increasingly the only way to catch fixes before attackers do.

For those who file vulnerability reports: The 90-day default is a historical artifact. If you’re reporting to a vendor with a large user base, consider whether the threat model actually justifies 90 days or whether a shorter, well-coordinated window reduces risk. There’s no one-size answer, but the question is worth asking explicitly.

For kernel and infrastructure maintainers using the “bugs are bugs” approach: The strategy isn’t broken, but it works less reliably now. Supplementing it with rapid advisory publication to distribution security lists — immediately on fix push, not after a delay — closes some of the gap. The window between “fix lands” and “attacker knows what was fixed” is narrowing regardless of your communication choices.

For AI security tooling builders: The same scanning capability that helps defenders identify security commits helps attackers. Tools that analyze commit streams for security relevance are dual-use by construction. This isn’t an argument against building them — defenders need them more than they’ve ever needed them — but it’s worth being explicit about when publishing or selling them.

---

The Copy Fail incident isn’t a story about disclosure going wrong. Everyone involved acted reasonably within the norms of their community. It’s a story about norms that evolved for a specific technological environment no longer fitting the environment. That’s a harder problem than anyone acting badly — it requires communities to renegotiate conventions that have worked well for decades, under time pressure, without a clear alternative.

---

Sources and references:

• Jeff Kaufman, AI is Breaking Two Vulnerability Cultures — jefftk.com (May 2026) — primary analysis this post responds to
• Hyunwoo Kim / V4bel, dirtyfrag write-up and disclosure timeline — GitHub
• oss-security mailing list thread, Copy_Fail2 announcement — openwall.com
• 0xdeadbeefnetwork, Copy Fail 2 write-up — GitHub
• Linux kernel commit f4c50a403 — kernel.org
• Anthropic, Using LLMs to secure source code — claude.com (June 2026)