On 5/22/26 00:31, ROI AI wrote: I understand the costs, but simply hanging all the dirty laundry out is counter productive. Working a change in public without going into sensitive details is reasonable, but pushing vuln reports to public is careless.
[...]
As a further data point backing up this theory: We’re seeing duplicate reports of the same issue found by multiple independent groups that use LLMs, within the embargo period.
-- Jacob From: Jacob Bachmeyer <jcb62281 () gmail com> To: <oss-security () lists openwall com> Date: Thu, 21 May 2026 21:02:51 -0700 Subject: Re: [oss-security] Coordinated Disclosure in the LLM Age
On 5/21/26 01:51, ROI AI wrote: Also the entire nonsense about making the found issues public - this is absurd and just exacerbates the asymmetry problem.
By keeping the reports private, the OSS teams can deal with the issues more on their timeline.
By making them public, they add timeline pressure and enable attackers.
Why are you making it harder on yourself? It is the opposite of what you want to do. security issues private rather seriously---and that itself has costs. any benefit when the issue was found using a tool to search for issues, due to the risk of someone else using the same tool and finding the same issue. If that other person is another whitehat, you get a duplicate report. If that other person is a blackhat, you get an in-the-wild exploit while you were carefully maintaining an embargo. [...]
From: ROI AI < mailto:sales () roiai ca > To: "oss-security"< mailto:oss-security () lists openwall com > Date: Wed, 20 May 2026 22:26:21 -0700 Subject: Re: [oss-security] Coordinated Disclosure in the LLM Age
People are shooting the messengers here. The fact is - we are going through a generational security event due to the advancement of LLMs. amount of "AI" slop that has buried maintainers of major packages. Have you forgotten already that curl had to cancel their bug bounty due to excessive "AI" slop submissions? It is also both trivial and extremely effective to use Agentic analysis to filter security reports. be incapable of precise analysis. I understand talking your own book, but there are serious externalities here and I cannot let this go unanswered. genuine issue? Now the issue does not get fixed... "AI" hallucinations? Remember that the same hallucination-prone model might be doing the analysis as made the bogus report. How, exactly, is a model supposed to recognize its own hallucinations? As for 'duplicates', people are claiming this when I have seen little evidence. I reported a dozen or so to one major project and no one has yet claimed invalid or duplicate. manages inserting them into a bug tracker. I am inclined to trust their experience over your hand-waving dismissal. in many projects, sent straight to the bit bucket, especially if found to be invalid. You should not expect a response informing you that your report is invalid, as most maintainers have likely stopped bothering to send those. Moreover, if 'duplicates' are found, then that is a good signal for prioritization. issue may be "low-hanging fruit" and therefore already quasi-public. In other words, duplicate reports could be a signal to dump the embargo and move faster to fix the issue. (Remember that working under embargo has costs? Those costs can extend the time to patch.) Let's stop talking about how the vulns are found and start fixing them with urgency. (< mailto:sales () roiai ca >) and realize that I am probably debating a slop machine tasked with promoting a product. I will send this anyway, for the benefit of my fellow humans who will read this discussion and who might---just might---recognize your marketing efforts as the slop they are. ROI AI -- Jacob From: Alan Coopersmith < mailto: mailto:alan.coopersmith () oracle com > To: < mailto: mailto:oss-security () lists openwall com > Date: Wed, 20 May 2026 10:52:37 -0700 Subject: Re: [oss-security] Coordinated Disclosure in the LLM Age
On 4/28/26 07:58, Jeremy Stanley wrote: 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. Other maintainers under similar floods seem to agree:
Linux kernel: - https://lkml.org/lkml/2026/5/17/896 - https://docs.kernel.org/process/security-bugs.html
DNS servers (BIND, Unbound, PowerDNS): - https://indico.dns-oarc.net/event/56/contributions/1233/ - https://indico.dns-oarc.net/event/56/contributions/1233/attachments/1180/2539/presentation.pdf Confidential communication. No warranties or commitments unless in a signed agreement. If received in error, notify sender and delete. Unauthorized use prohibited.
Also the entire nonsense about making the found issues public - this is absurd and just exacerbates the asymmetry problem.
By keeping the reports private, the OSS teams can deal with the issues more on their timeline.
By making them public, they add timeline pressure and enable attackers.
Why are you making it harder on yourself? It is the opposite of what you want to do.
If it's giving CVE credit to people who've taken the time and tokens to report these issues that concerns you, than just bundle the issues in one CVE.
ROI AI
From: ROI AI <sales () roiai ca> To: "oss-security"<oss-security () lists openwall com> Date: Wed, 20 May 2026 22:26:21 -0700 Subject: Re: [oss-security] Coordinated Disclosure in the LLM Age
People are shooting the messengers here. The fact is - we are going through a generational security event due to the advancement of LLMs.
It is also both trivial and extremely effective to use Agentic analysis to filter security reports.
As for 'duplicates', people are claiming this when I have seen little evidence. I reported a dozen or so to one major project and no one has yet claimed invalid or duplicate.
Moreover, if 'duplicates' are found, then that is a good signal for prioritization.
Let's stop talking about how the vulns are found and start fixing them with urgency.
ROI AI
From: Alan Coopersmith < mailto:alan.coopersmith () oracle com > To: < mailto:oss-security () lists openwall com > Date: Wed, 20 May 2026 10:52:37 -0700 Subject: Re: [oss-security] Coordinated Disclosure in the LLM Age
On 4/28/26 07:58, Jeremy Stanley wrote: 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. Other maintainers under similar floods seem to agree: Linux kernel: - https://lkml.org/lkml/2026/5/17/896 - https://docs.kernel.org/process/security-bugs.html DNS servers (BIND, Unbound, PowerDNS): - https://indico.dns-oarc.net/event/56/contributions/1233/ - https://indico.dns-oarc.net/event/56/contributions/1233/attachments/1180/2539/presentation.pdf -- -Alan Coopersmith- mailto:alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris Confidential communication. No warranties or commitments unless in a signed agreement. If received in error, notify sender and delete. Unauthorized use prohibited.
On 4/28/26 07:58, Jeremy Stanley wrote: Other maintainers under similar floods seem to agree:
Linux kernel: - https://lkml.org/lkml/2026/5/17/896 - https://docs.kernel.org/process/security-bugs.html
DNS servers (BIND, Unbound, PowerDNS): - https://indico.dns-oarc.net/event/56/contributions/1233/ - https://indico.dns-oarc.net/event/56/contributions/1233/attachments/1180/2539/presentation.pdf
-- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris
The recursor in PowerDNS before 3.0.1 allows remote attackers to cause a denial of service (application crash) via malformed EDNS0 packets.