oss-security - Sv: Coordinated Disclosure in the LLM Age

Follow @Openwall on Twitter for new release announcements and other news
[<prev] [<thread-prev] [day] [month] [year] [list]
Message-Id: <19e2e0e48e7.65e04bb445073.6153883981537660891@roiai.ca>
Date: Fri, 15 May 2026 16:52:28 -0700
From: ROI AI <sales@...ai.ca>
To: "oss-security" <oss-security@...ts.openwall.com>
Subject: Sv: Coordinated Disclosure in the LLM Age

Not sure I understand this feedback.  Openstack has a lot of low hanging vulnerabilities due to legacy code.  This is the central issue, not me or LLMs.  



A lot of people are clamoring for sovereign cloud right now:  https://news.ycombinator.com/item?id=48120629 

An example:   https://bugs.launchpad.net/swift/+bug/2152384/comments/14 


ROI AI








From: Markus Klyver <markusklyver@...mail.com>
To: "oss-security@...ts.openwall.com"<oss-security@...ts.openwall.com>
Date: Fri, 15 May 2026 08:27:57 -0700
Subject: Sv: [oss-security] Coordinated Disclosure in the LLM Age



If you want to process your all your internal thoughts and personality through a statistical probabilistic function, then you are of course absolutely entire free to do so. But please keep in mind that LLMs are also overloading open source projects with fake PRs and "fixes" that ruin the codebase (do I have to mention ffmpeg and curl?), the code quality and the lives of everyone. 
 
If an LLM is used to find potential bugs, it is up to you to ensure it is a real bug and that you can replicate the behavior. Offloading that part to the LLM and the need for human knowledge is a loss for everyone involved. 
________________________________ 
Från: Tim Shephard < mailto:tim@...ai.ca > 
Skickat: den 12 maj 2026 03:22 
Till: oss-security < mailto:oss-security@...ts.openwall.com >; fungi < mailto:fungi@...goth.org > 
Ämne: Re: [oss-security] Coordinated Disclosure in the LLM Age 
 
Thanks for starting this discussion.  I have reported a number of issues recently, including - #2149789,  #2150261,  #2149775,  #2150316 - three of which are identified by the team as critical, and one as high.  The oslo rabbit MITM is also critical, IMHO, but I agree it cannot be fixed without potentially breaking many poorly configured deployments and so must be 'Class B'.  An awkward situation to be sure, but the solution is understandable. 
 
For what it's worth my goal is not to 'mine security gold', rather I am trying to find and test potential solutions for sovereign cloud. 
 
 
 
More to the point of the thread, I think there is also a more pressing issue adjacent to the disclosure-process question: large, long-lived projects such as OpenStack have a substantial backlog of legacy vulnerabilities and insecure patterns that are now becoming much easier to discover with LLM assistance. 
 
That changes the risk calculation. Issues that previously required deep project knowledge, persistence, or specialized tooling may now be within reach of many more people. We should assume adversaries can use the same leverage, including for insider attacks and for chaining individually modest bugs across trust boundaries. 
 
In that sense, this feels like a generational security event. The urgent question is not only whether embargoed details might leak through LLM use, but whether maintainers can harden exposed systems faster than attackers can rediscover and combine old weaknesses. 
 
That argues for shorter exposure windows, more proactive hardening, and more attention to eliminating vulnerable patterns before they become practical attack paths. 
 
Furthermore, it argues for assertive use of modern LLMs, especially for code review and vulnerability discovery. I have volunteered to help with this for the OpenStack VMT, and would be happy to do so again here. 
 
 
 
Cheers, 
 
 
 
Tim. 
 
PS: LLMs helped with this email, and with more and more of the work I do. I think we need to move forward with these tools more deliberately and less fearfully. 
Confidential communication. No warranties or commitments unless in a signed agreement. If received in error, notify sender and delete. Unauthorized use prohibited.
Confidential communication. No warranties or commitments unless in a signed agreement. If received in error, notify sender and delete. Unauthorized use prohibited.
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.