LLM-driven security reports disrupt coordinated disclosure [LWN.net]

By Joe Brockmeier
May 6, 2026

Predictions that LLM tools would cause a surge in reports of security vulnerabilities have, unquestionably, borne out. As expected, maintainers are having to wade through more security reports than ever before; in addition, LLM tools are disrupting traditional-coordinated disclosure practices as well. The method of Copy Fail's disclosure, in particular, left vendors, projects, and users scrambling. In addition, maintainers are seeing parallel discovery of the same security flaws within the embargo window. Both of these developments mean that coordinated security disclosures may become a thing of the past.

"Mining security gold"

Jeremy Stanley, a member of the vulnerability management team for the OpenStack cloud-computing project, brought this topic to the OSS Security mailing list on April 28. He said that projects he worked on "are under a seemingly unending deluge of reports from researchers using LLMs to mine for security gold in our software". That had led to him thinking about the risks that public LLM services might pose to traditional vulnerability-handling workflows, embargoes, and coordinated disclosure of security flaws. He wondered if it would be helpful to keep embargoes short to mitigate the risks of parallel discovery or disclosure to other LLM users.

I'm sorely tempted, both due to the increased volume and the risk of premature disclosure, to just assume that any vulnerability reported as a result of research using an LLM is trivially discoverable by others, and give up trying to pretend there's any point to working it under embargo. Similarly, it makes sense to me that patch development and descriptive prose shouldn't be produced with LLM assistance for any vulnerability that is being worked under an embargo.

He said that he could not be the only one thinking about this topic, and asked what others thought. Jacob Bachmeyer replied that parallel discovery was a big risk: "If an LLM can find a bug for a whitehat, it can do the same for a blackhat. [...] LLM-discovered vulnerabilities should be considered already publicly known".

Effect on embargoes

If the vulnerabilities are (arguably) known to multiple people, the question arises of whether standard practices around security embargoes still make sense. Lucas Holt said that he saw "the logic and temptation" of shortening embargoes, but dropping a zero-day exploit on a small project would not help anyone. He suggested that large projects may have multiple people looking for and discovering the same flaws, but smaller projects were unlikely to have multiple people probing them for vulnerabilities at the same time.

Stanley clarified that he was approaching the problem from the perspective of "an upstream maintainer and vulnerability coordinator of large/popular projects receiving these reports". He was seeing a flood of reports, and that trying to manage all of them in private was leading to "accidents breaking our embargoes before things are ready or distros/deployers have been given sufficient advance warning". If security reports were public immediately, he thought projects could crowdsource help from a larger portion of their community "rather than relying solely on overwhelmed vulnerability coordinators and security-focused maintainers".

Holt had suggested that people who used LLMs to find security bugs could also use their tools to create patches. Brian May warned people to be careful of that approach. "Simple patches that look good can in fact be hiding serious security issues. Thinking of the September 2006 Debian openssl issue here."

Greg Dahlman also thought that LLMs were unreliable when it comes to creating security fixes. He described the ability of current LLMs to produce correct and secure code as being within "the coin flip range"; in other words, he thought there was only a 50-50 chance that an LLM's suggested solution to fix a flaw would be adequate. Therefore, any embargo timeline needed to take into account the asymmetry between the time it takes to discover a flaw and the time needed to actually fix it.

Already happening

It turns out that Stanley's hypothesis about parallel discovery had already been proven in the wild. Clemens Lang, who works on the Red Hat Enterprise Linux (RHEL) crypto team, provided a data point to support the theory: "We're seeing duplicate reports of the same issue found by multiple independent groups that use LLMs, within the embargo period." Greg Kroah-Hartman also reported that kernel developers were "seeing duplicate reports of the same issue from different groups within the time period it takes to get a fix merged".

Willy Tarreau said that he had predicted the death of security embargoes months ago:

Embargoes now play against security, for all the time we don't act, users stay exposed to anyone having the luck to find the same problem. It's not a matter of the LLM's strength but a matter of determination by the researcher who could simply run a small model several times helping it dig further. Bigger models just find faster, but that only counts for those seeking protection, not for those trying to attack.

Copy Fail disclosure fail

The Copy Fail privilege-escalation vulnerability (CVE-2026-31431) was announced on April 29 by Xint. It is a "straight-line logic flaw", meaning that it does not require race conditions or other special circumstances, that allowed local users to trivially get root access on most Linux distributions unless they had the most up-to-date kernels.

Along with the announcement, there was a proof-of-concept (POC) Python script that allowed users to see if their systems were vulnerable. The fix had already been included with the 7.0, 6.19.12, and 6.18.22 kernels, but was not available as a backport to older stable kernels until April 30. Most Linux distributions were caught with their proverbial pants down. On April 30, with a POC showing how to exploit the vulnerability widely available, major distributions such as Debian, Red Hat Enterprise Linux, SUSE, and Ubuntu had no fix ready for their users.

It was described as "one of the worst make-me-root vulnerabilities in the kernel in recent times" by Eddie Chapman on the OSS Security list. He wondered what went wrong:

Has the embargo been broken early today? Not looking to point any fingers, those who make things happen in our communities work dam hard and deserve respect and support, especially with the extra burden of AI slop now.

Gentoo contributor Sam James said that it's up to security reporters to notify Linux distributions of kernel vulnerabilities: "unless the reporter chooses to bring it to the linux-distros [mailing list], there is no heads-up to distributions. It did not happen here."

The discussion turned to something of an ad-hoc postmortem, fingerpointing, and problem-solving session. Alexander Peslyak, who goes by "Solar Designer", said that distributions had little way of knowing about the importance of this vulnerability, as it did not stand out among all the others.

The vulnerability was reported to the kernel team on March 23, according to the timeline in Xint's announcement. A patch was committed to the mainline kernel on April 1. CVE-2026-31431 was added to the kernel's security repository on April 25, with a Common Vulnerability Scoring System (CVSS) score of 7.8 (out of a possible ten), four days before the Copy Fail announcement. Peslyak pointed out that there were 168 CVEs in the batch from that day, with scores between 7.1 and 9.8. "By the score alone, this one really does not stand out. To me, this is usual noise, with little signal in there." It did not hint at the severity or imminent threat of a POC being released. In fact, there are 21 CVEs added on April 25 that have a "9.8 CRITICAL" CVSS score.

Greg Kroah-Hartman replied that the kernel team's "constant message", for decades, has been that users must upgrade to the latest release to ensure that they have all of the fixes for currently known issues. He added that the kernel team had no knowledge of the Copy Fail announcement ahead of time "as no one is obligated to tell us that they are about to let loose a trivial exploit", and that the team was not allowed to notify others ahead of time, lest they have to tell everyone about everything. "That's the only policy by which all the legal/governmental agencies have agreed to allow us to operate in, so we are stuck with it."

On May 3, James shared a link to a comment from Brian Pak of Xint that said the company had provided a fully working exploit to the kernel security team when the vulnerability was reported. "We've since learned that such details don't automatically get forwarded downstream and that Linux kernel commit messages are typically kept minimal. That's simply how the process works." James said that the kernel team "were very much aware of the impact from the offset", and inquired if the kernel team was "honestly proud of how this went".

The CVE garbage patch

Kroah-Hartman asked exactly what James would suggest that the kernel team do better, and how it should do it. He added that the team receives bug reports of local-user privilege-escalation bugs all the time; it was not obvious that this one was special until after the fact because the submitter used it to show off their software. "That is something that normally does not happen and is outside of the control of all of us involved here." Emily Shepherd wanted to know if the POC or a description of the flaw's severity had been provided; Kroah-Hartman replied that he honestly did not remember because "that was months and hundreds, if not thousands, of reports ago". He also reminded the list how the kernel security team operates:

The job of the kernel security team is to triage a bug report, drag in the relevant maintainer/developer, get the issue fixed and merged into Linus's tree as soon as possible. Once it lands in Linus's tree, our role is over.

We do not do "announcements" of anything to anyone, so even if this was a "look how bad you can abuse the system" type of thing, we would not be telling anyone anything.

He added that he's documented this in detail, given many talks about it, and has been blogging about it as well.

On social media, Josh Bressers suggested that the blame lies with the company: "every AI vulnerability company wants to find something juicy, and have no idea how to coordinate the findings". Kroah-Hartman dismissed the idea that coordination of vulnerabilities was even possible now. Bressers agreed: "I do think you're right that the traditional disclosure model is gone forever". He did think it was "pretty obvious" that Copy Fail would be a big one; but he had no idea what to do to prevent important vulnerabilities from drowning in the "great CVE garbage patch".

Copy Fail is just one vulnerability out of thousands. At the rate that LLM tools seem to be speeding up discovery, it does seem that Kroah-Hartman has a point. Traditional disclosure notification is becoming increasingly difficult, if not outright impossible. The volume of reports, coupled with the fact that many AI-assisted reporters will be unfamiliar with how security disclosure usually works, means that relying on embargoes and coordinated fixes is going to be increasingly risky. We live in interesting times for open-source security, whether we want to or not.

to post comments

Wrong metric

Posted May 6, 2026 16:14 UTC (Wed) by kleptog (subscriber, #1183) [Link] (3 responses)

> Greg Dahlman also thought that LLMs were unreliable when it comes to creating security fixes. He described the ability of current LLMs to produce correct and secure code as being within ""the coin flip range""; in other words, he thought there was only a 50-50 chance that an LLM's suggested solution to fix a flaw would be adequate.

The test is not whether the fixes produced by LLMs are any good in general. The test is whether LLMs are more likely to produce a valid fix than some random security researcher that doesn't know the code base. I'd argue probably yes.

Sure, the core developer of the project is more likely to create the correct fix. But if you're asking other random people to submit fixes, they may as well use LLMs to do them. Generate the test cases while they're at it.

Wrong metric

Posted May 6, 2026 16:43 UTC (Wed) by koverstreet (subscriber, #4296) [Link] (2 responses)

Yup, this.

I've noticed a sharp _increase_ in the quality of PRs submitted to bcachefs since people started using LLMs.

Are they always correct? No - the ratio of PRs that I can merge vs. PRs that need rework or I have to kick back because they're the wrong approach is probably about the same.

But, at least for bcachefs, people are clearly using LLMs right: researching the problem with the LLM (not "vibe coding" and just trusting the LLM), so I'm seeing a lot more thought put into the same amount of code, and commit messages have gotten _much_ better.

Even if the code in the PR is wrong, if the thought and research is there and in the commit message, that's immensely valuable - writing the code is usually not the hard part, the hard part is (correctly) identifying the problem and researching approaches.

I must say I've been enjoying it.

Wrong metric

Posted May 7, 2026 5:12 UTC (Thu) by kleptog (subscriber, #1183) [Link] (1 responses)

> Even if the code in the PR is wrong, if the thought and research is there and in the commit message, that's immensely valuable - writing the code is usually not the hard part, the hard part is (correctly) identifying the problem and researching approaches.

Reminds me of my experience with patches for PostgreSQL. I might spend quite some time trying different approaches and end up posting a patch that gets completely rewritten by a core developer. It's just way easier for an experienced developer to start from a situation they know works and fixes the problem to make something that's better. The submitted patch describes the areas of the code that need to be changed, which locking/assumptions are problematic and the test cases are always useful.

Even if none of the original lines of code survive to the final commit, the initial patch was still valuable. An LLM that generates a fix, tests that it compiles and actually solves the problem is valuable, even if the actual code is never merged.

And writing good commit messages really goes to a core strength of LLMs.

Wrong metric

Posted May 7, 2026 8:18 UTC (Thu) by vasvir (subscriber, #92389) [Link]

This definitely rings a bell.

The thing is all of it lives in temporal memory and is one context switch away from deletion.

Most of the times the research is not properly recorded. And how could it?

In best case scenario I have read comments from me like:

/* So this is approach C that actually works while the obvious ones A and B are not. */

The commit might say something more - maybe not.

While A, B and C can be short explanations and not just names, 3 months later I cannot remember what A and B were about and why C looks so weird?

I appreciate Greg KH's candor

Posted May 6, 2026 17:01 UTC (Wed) by IanKelling (subscriber, #89418) [Link] (1 responses)

It implies to me that distros should pick up some slack and it makes sense.

I appreciate Greg KH's candor

Posted May 7, 2026 11:15 UTC (Thu) by fuhchee (guest, #40059) [Link]

"Someone else needs to do this work properly because we won't."

Embargos should stay, but everyone needs to be notified

Posted May 6, 2026 18:34 UTC (Wed) by jpeisach (subscriber, #181966) [Link] (11 responses)

I don't think we need to reinvent the wheel here. An LLM being able to find a vulnerability that is already known and under embargo, is not surprising. But it's like if someone else happened to find the same vulnerability.

Then it's just responsible disclosure.

But still, just because an LLM *COULD* find it, doesn't mean everyone will have their attention on the vulnerability.

By public disclosure, then everybody knows what the bug is without allowing time for people to patch. That's what the big issue is.

Embargos should stay, but everyone needs to be notified

Posted May 6, 2026 18:47 UTC (Wed) by wtarreau (subscriber, #51152) [Link] (6 responses)

There's not much responsible disclosure anymore. Less than a week ago, an issue was reported on the security list, being handled responsibly by maintainers and the reporter working together. Another person arrived and said the usual "I found this bug I want my CVE blablabla", we said "it's already being handled", the first reporter said "smells bad, I bet you that it will be disclosed". And he bet right, it happened just a few hours later.

Most people using LLMs to find bugs do it because it's fun. They're PLAYING. If you tell them they've lost, there's still one option to win, which is not to follow the well-established rules.

Embargoes are just keeping people at risk. What is important however is to ponder on what level of detail to place in commit messages. I.e. explain the problem without explaining how to reproduce it. I don't know how long it will last though, since some bugs' consequences are now found after they're public, and LLMs continue to improve and will soon automatically turn a patch into an exploit.

We'll soon end up with a continuous stream of fixes from upstream to end users to keep them protected. On the other hand the situation is harsh for everyone now because 15 year-old bugs are being discovered en masse. Hopefully in a few months it will be much better already.

Embargos should stay, but everyone needs to be notified

Posted May 6, 2026 19:32 UTC (Wed) by koverstreet (subscriber, #4296) [Link] (5 responses)

I'm not so sure.

I don't expect the current situation to last; LLMs are shiny and new, but there are a finite number (approximately) of bugs in any given codebase, and eventually most of them will be found, and at the same time we're moving to Rust - and LLMs are also going to help with making that transition a lot faster.

IOW, I don't think we should overreact.

I'm not really pro embargo either, but I don't think a week or two (not more than that) is unreasonable if there's a fix in flight and it just needs to make it through the usual channels.

However - it seems a lot of distros _weren't_ notified or included in the embargo period for the AEAD sockets bug, and embargoes don't do any good if the appropriate people aren't being notified - so if that isn't being rectified, yes, we are better off without them.

Embargos should stay, but everyone needs to be notified

Posted May 7, 2026 2:17 UTC (Thu) by brian_lindholm (subscriber, #42351) [Link] (4 responses)

LLMs are shiny and new, but there are a finite number (approximately) of bugs in any given codebase, and eventually most of them will be found... IOW, I don't think we should overreact.

Agreed, and I think this is an underappreciated point. LLMs have increased the volume of of bug reports for now, but I don't think they'll stay elevated forever. Eventually the number of bugs available to find will fall, and the volume of reports should go down. And at the end of the process, we'll hopefully have a code base with a bugs-per-LOC metric lower than ever before. Getting there, though... Hoo boy. It's going to be rough for a while.

Embargos should stay, but everyone needs to be notified

Posted May 8, 2026 4:36 UTC (Fri) by wtarreau (subscriber, #51152) [Link] (3 responses)

> > LLMs are shiny and new, but there are a finite number (approximately) of bugs in any given codebase, and eventually most of them will be found... IOW, I don't think we should overreact.

> Agreed, and I think this is an underappreciated point. LLMs have increased the volume of of bug reports for now, but I don't think they'll stay elevated forever. Eventually the number of bugs available to find will fall, and the volume of reports should go down. And at the end of the process, we'll hopefully have a code base with a bugs-per-LOC metric lower than ever before.

Oh don't get me wrong, this has been my point for a few months now, many projects suggest that we'll be in a bad situation until the end of the year approximately, and that past this point the code quality will have significantly improved. However I do think that release processes will have improved as well to avoid embargoes and nobody will find it necessary to get back to this old crap that magnifies laziness, paperwork, incompetence and irresponsibility. Those having been on disclosure platforms know how pathetic the situation is with any "bug" reported there, where the reporters have their moment of glory reporting crap, embargoes lasting 2-6 months during which everyone except a few say "not affected" but users of the few affected ones live in danger with no fix available despite hundreds to thousands of people being aware of their problem.

The situation must change so that software makes it easier to disable certain features while gracefully degrading the service. On Linux you can disable some modules without rebooting. I would like it if it was also possible to disable certain address families in /proc or /sys, if we could disable certain namespace types (USER_NS typically), or if we could globally disable splicing when a big vuln is reported (remember that vmsplice was already a thing 18 years ago and provided LPE again 5 years ago, so it looks like a recurrent pattern). etc.

Without embargos we could force ourselves to make software a bit more resilient, not always imagining that "users must just upgrade", but thinking "what knob could we offer to instantly kill a class of bugs". And that would help not just with security but also with stability.

Disabling user namespaces breaks browsers

Posted May 8, 2026 7:58 UTC (Fri) by DemiMarie (subscriber, #164188) [Link] (1 responses)

Disabling user namespaces breaks browser sandboxes, so for most client systems it’s not a viable option. Yes, flatpak also breaks browser sandboxes, but this needs to be fixed in flatpak, possibly via D-Bus containerization.

Disabling user namespaces breaks browsers

Posted May 8, 2026 8:13 UTC (Fri) by wtarreau (subscriber, #51152) [Link]

Yes but millions of production servers just do not need that and are regularly exposed to CAP_NET_ADMIN bugs that are triggered via this vector. The principle is interesting in concept, but it doesn't apply well to old code that was already around before namespaces existed, and that was designed with the principle that "we trust root", which was later updated to "we trust CAP_NET_ADMIN or CAP_SYS_ADMIN" without checking closely what "trust" means in the context of namespaces. Yet I don't see how they can disable this mechanism they don't need (except by rebuilding the kernel).

Embargos should stay, but everyone needs to be notified

Posted May 8, 2026 10:01 UTC (Fri) by Wol (subscriber, #4433) [Link]

> Without embargos we could force ourselves to make software a bit more resilient, not always imagining that "users must just upgrade", but thinking "what knob could we offer to instantly kill a class of bugs". And that would help not just with security but also with stability.

It would also help with upgrading in general. Run-time (and compile time?) knobs to disable classes of deprecated features (off by default). Yes we have the long tail of users who don't upgrade, but we can make sure new software is lean, clean, and *modern* with backwards compatibility available on demand.

Cheers,
Wol

Embargos should stay, but everyone needs to be notified

Posted May 6, 2026 19:25 UTC (Wed) by mb (subscriber, #50428) [Link] (1 responses)

>But still, just because an LLM *COULD* find it, doesn't mean everyone will have their attention on the vulnerability.

It's just a matter of somebody else pointing an LLM agent at it and prompting it to analyze it for bugs.

These agents eat through hundreds of thousands of lines code relatively quickly and will pretty reliably report the same bugs over and over again, no matter who prompted it and how it was prompted.

This also works very well on a delta basis if you point it at a commit range of interest.
It's safe to assume that the commit stream going into any major project is going into LLM bug finding agents the moment it is pushed to public.

Embargos should stay, but everyone needs to be notified

Posted May 6, 2026 22:11 UTC (Wed) by jpeisach (subscriber, #181966) [Link]

> It's just a matter of somebody else pointing an LLM agent at it and prompting it to analyze it for bugs.

Yes, but don't encourage people to go looking after them is my point

Embargos should stay, but everyone needs to be notified

Posted May 6, 2026 22:42 UTC (Wed) by sashal (✭ supporter ✭, #81842) [Link]

Isn't "everyone needs to be notified" == "public disclosure"?

Embargos should stay, but everyone needs to be notified

Posted May 7, 2026 5:18 UTC (Thu) by kleptog (subscriber, #1183) [Link]

> By public disclosure, then everybody knows what the bug is without allowing time for people to patch. That's what the big issue is.

The nice thing about copy.fail was that there was a fairly straightforward mitigation available (disable the kernel module loading) for most people. We even joked that it would be possible for someone to make a worm that effectively patched systems as it spread. There were some legacy systems here where I used the exploit to get root to install the mitigation.

Not all bugs are so easy to mitigate. An issue in a TLS stack is much harder to install a mitigation for.

You could argue once a useful mitigation is available, an embargo's value is basically gone.

The 'burn down the system' approach is finally starting to work

Posted May 6, 2026 19:13 UTC (Wed) by bluca (subscriber, #118303) [Link] (1 responses)

> but he had no idea what to do to prevent important vulnerabilities from drowning in the "great CVE garbage patch".

That's great, it looks like the "burn down the system" strategy ( https://www.youtube.com/watch?v=HeeoTE9jLjM&t=1686s ) is finally starting to work! I guess maybe we all misunderstood, and it's not the security tracking system that they wanted to burn down, but every production system running Linux which got pwned thanks to these shenanigans. Close enough!

I wonder if there's anybody honestly taking seriously the stream of absolute garbage that comes out of the kernel CNA anymore these days? If so, it seems to me it's high time to stop and just ignore them, and get professionals who actually understand what they are doing to analyze these reports, and provide actual, sensible triaging

They won’t do triage for you

Posted May 8, 2026 8:03 UTC (Fri) by DemiMarie (subscriber, #164188) [Link]

Either upgrade, do triage yourself, or pay someone to. Personally, I would just upgrade weekly. An application that can’t tolerate weekly maintenance windows should have application-level redundancy.

Oh, it must be Tuesday again.

Posted May 6, 2026 19:48 UTC (Wed) by gmprice (subscriber, #167884) [Link] (1 responses)

Everything has always been this broken, and embargoes didn't make things any less broken they just gave people time to react... If you were one of the few parties lucky enough to be in the circle that graces you with knowledge. For the rest, you weren't any better off for it.

The only difference today is the bar for entry. No longer is research gated by access to massive amounts of man hours or compute power - just by what codebase we point the tokens at.

But let's not pretend like we didn't already know how bad the state of code in general is. It's always been this bad. What are the chances Copy Fail hadn't already been found some many years ago and was in-use? Very little.

Maybe folks will take this as a reason to invest more heavily in the maintenance of open source software as opposed to take for granted the folks trying to keep up with the deluge.

It's just another Tuesday.

---

"For you, the day Bison graced your village was the most important day of your life. But for me... it was Tuesday" ~ M Bison, Street Fighter

Oh, it must be Tuesday again.

Posted May 6, 2026 19:51 UTC (Wed) by koverstreet (subscriber, #4296) [Link]

> But let's not pretend like we didn't already know how bad the state of code in general is. It's always been this bad.

hey, people are finally noticing :)

This argument is about to be moot

Posted May 7, 2026 1:50 UTC (Thu) by geofft (subscriber, #59789) [Link] (4 responses)

If it really is true that general-access LLMs can find the sorts of bugs that are being reported under embargo (and I believe it, myself), then there's no point arguing about whether there should be an embargo or not. We're very lucky that the multiple people operating LLMs are choosing to disclose it to embargoed security-report lists (discounting, of course, any attackers that may also be operating LLMs in the same way). There is no particular reason this should be true. Sooner or later someone will find it amusing to spend money on having LLMs find bugs, categorize their severity, and automatically report them to fulldisclosure@.

In the shorter term, I think the practice of treating security bugs as "regular" bugs will also go by the wayside, too; it doesn't matter what's in the kernel commit message because it's easy to ask an LLM to look at every single commit diff, ignoring the commit message, and spend some time figuring out whether it fixes an exploitable bug. There have been heuristics for humans to try to find which kernel patches are serious, e.g, if the commit message sounds like general code hygiene that doesn't even fix a real bug, but the "Reported-By" is a Project Zero employee, probably it secretly fixes a very serious bug. An LLM has no need for these kinds of heuristics to filter which commits to look at. You can just parallelize LLMs looking at them all, and they won't get tired.

Remember, given enough eyeballs, all bugs are shallow, and increasing the number of LLM attention heads looking at your code is a way more scalable process than training a single pair of qualified human eyeballs.

This argument is about to be moot

Posted May 7, 2026 8:32 UTC (Thu) by nim-nim (subscriber, #34454) [Link] (1 responses)

> Sooner or later someone will find it amusing to spend money on having LLMs find bugs, categorize their severity, and automatically report them to fulldisclosure@.

Well what that actually means is that all the companies and organisations caught with their pants down by the latest security incidents better subsidise quickly a robot to do this kind of triaging and report the result to their own security teams. It’s the usual MAD where the only way to get back to the previous status quo is for everyone to escalate in parallel.

This argument is about to be moot

Posted May 7, 2026 11:27 UTC (Thu) by farnz (subscriber, #17727) [Link]

Or, longer-term, someone starts running high-end security analyzers (including LLM-based ones) on the code much earlier in the pipeline, so that while releases get delayed by someone finding the issues and having to fix them (which, in turn, will put pressure on companies and organisations to choose languages where the analyzers don't find issues because the idioms used prevent the programmer making those mistakes), there's not many security issues left out in the wild for these tools to find, and thus we don't ever get back to the previous status quo.

This argument is about to be moot

Posted May 8, 2026 4:55 UTC (Fri) by wtarreau (subscriber, #51152) [Link]

> If it really is true that general-access LLMs can find the sorts of bugs that are being reported under embargo (and I believe it, myself),

I can confirm it, I tried myself yesterday without giving much help to the LLM and it did find something that was already in the process of being fixed. It's accessible to the masses, really. Note that they don't even need to inspect commits anymore, you can explain them what to look for and feed them with an entire project. They read 1000 times faster than you and have 10000 times more short-term memory to spot correlations etc. They're *very* efficient at finding bugs, and that's why we're in the current situation. In parallel, projects are using them to try to discover their bugs before attackers with the same tools.

> then there's no point arguing about whether there should be an embargo or not. We're very lucky that the multiple people operating LLMs are choosing to disclose it to embargoed security-report lists (discounting, of course, any attackers that may also be operating LLMs in the same way).

That's what is currently happening. Some reporters are more professional than others and try hard to help with reports that are useful to maintainers.

> There is no particular reason this should be true. Sooner or later someone will find it amusing to spend money on having LLMs find bugs, categorize their severity, and automatically report them to fulldisclosure@.

It's already happening as well. Some reporters who learn that their issue was already reported and is already in the process of being fixed just find it funny to disclose it earlier in a last attempt to have fun or boost their ego before the fix lands everywhere. We saw that this week.

This argument is about to be moot

Posted May 8, 2026 8:20 UTC (Fri) by taladar (subscriber, #68407) [Link]

The point of treating security bugs as regular bugs is more that it is a waste of time to judge security impact when 90%+ of all bugs turn out to have some security implications.

baby bathwater much?

Posted May 7, 2026 12:14 UTC (Thu) by kiko (guest, #69905) [Link]

I find this discussion reductionist. Yeah, the embargo and disclosure process has always been flawed. But flawed processes often have non zero utility. From my own exposure to distro security I can say there is a surprising amount of useful discussion that leads to better end user mitigation and docs, dependency end of life decisions, toolchain improvement. We can't stop reporters from blowing embargos from their side, but we can keep setting expectations of professional behaviour. Organizations can still act responsibly and work together to minimize end user damage. Surf's up but at some point the stream of low hanging fruit will subside -- it would be nice for civilized conduct to survive meanwhile.