oss-sec Debates Coordinated Disclosure Risks from LLMs

The oss-sec mailing list hosted an extended thread in April and May 2026 about coordinated vulnerability disclosure in the era of large language models. Per the seclists.org archive, Jacob Bachmeyer posted multiple replies in May 2026 describing that he had reported a dozen issues to OpenStack and saying he was disappointed that "a serious security bug I reported on OpenStack [was] pushed to public" (seclists.org, May 21 and May 25, 2026). ROI AI posted several replies on May 20-21, 2026 arguing that publishing vulnerability reports can be "counter productive" and that LLMs enable harvesting careless public disclosures (seclists.org). Greg Dahlman posted to the list on April 28, 2026, recommending a 14-day "maximum acceptable embargo period" for issues disclosed to oss-sec and criticizing what he called a provider "common dark pattern" of implicitly opting non-enterprise users into data collection for model training (Let's Data Science, April 28, 2026). The seclists.org thread includes a quoted note from Clemens Lang of the RHEL Crypto Team, dated April 29, observing duplicate reports of the same issue found by multiple independent groups using LLMs during embargo periods (seclists.org).

Industry-pattern observations note that LLMs reduce the search and pattern-matching cost for finding software issues, which can increase both benign duplicate reports and adversarial discovery. Trained models and agentic tooling can surface similar leads to multiple researchers or attackers in parallel, shortening the effective window in which an issue is private. Dahlman's post, as reported by Let's Data Science, contrasted short embargo windows against multi-week or multi-month model-training cycles and quoted provider behavior such as Cursor's agent file-read behavior as an example of differing discovery and risk profiles (Let's Data Science, April 28, 2026).

Open-source maintainers and security lists have historically relied on embargoes to coordinate patching, but the thread documents a practical tension: several participants argue that issues found via public LLMs should be treated as potentially already public. The quoted observation from Clemens Lang that multiple independent LLM-using groups reported the same issue during an embargo period is a concrete data point cited on seclists.org that reinforces that tension. ROI AI's contributions to the thread invoked operational impacts on maintainers and referenced community incidents, including high-volume low-quality AI-generated submissions that have affected projects, as reported in the thread (seclists.org).

For observers and practitioners, the thread highlights these measurable signals: duplicate reports of the same flaw arriving during embargo windows; public release or accidental posting of proof-of-concept code; explicit policy changes from model providers around data collection or training opt-ins; and maintainers adopting shorter disclosure timelines or modified triage rules for LLM-identified issues. Industry reporting and the oss-sec exchanges make clear these are active, observable items members of the security and maintainer community are already tracking (seclists.org; Let's Data Science).

The oss-sec discussion aggregates practitioner experience and emerging norms rather than announcing a coordinated policy shift. The thread documents real incidents and recommends changes (for example, Dahlman's 14-day proposal), and it surfaces an operational trade-off between careful embargo-based coordination and the practical risk that LLM-enabled discovery will duplicate or preempt private disclosure (seclists.org; Let's Data Science).