Coordinated Vulnerability Disclosure in the AI Era: What Changes When AI Finds the Bugs

The traditional coordinated vulnerability disclosure process follows a structured sequence. A security researcher discovers a vulnerability in a vendor's software. The researcher notifies the vendor privately, providing technical details sufficient to reproduce and understand the issue. The vendor acknowledges receipt and begins internal analysis. The researcher and vendor agree on a disclosure timeline, typically 90 days from initial notification. During that window, the vendor develops and releases a patch. After the 90-day window (or upon patch release, whichever comes first), the researcher publishes their findings, typically including a CVE assignment, technical details, and proof-of-concept code.

This process was designed to balance two competing interests: the vendor's interest in having time to patch without public exposure, and the researcher's (and user community's) interest in ensuring that vulnerabilities do not stay secret indefinitely. The 90-day standard emerged as a compromise that the security community broadly accepted, with some variation for critical infrastructure findings that might warrant extended timelines.

The traditional CVD model assumes a manageable flow of disclosures that vendor security teams can process one at a time. A typical large software vendor might receive dozens of external vulnerability reports per year through bug bounty programs and researcher outreach. Their security response teams are sized accordingly.

Glasswing issued 1,596 CVD disclosures in 90 days. For context, that is roughly 17 disclosures per day, every day, for three months. More significantly, these are not low-quality crash reports from automated fuzzers. Anthropic's disclosure notifications come with validated exploit chains and CVSS assessments reviewed by human security researchers. The quality bar is higher than most bug bounty submissions.

The vendors and organizations receiving these notifications did not budget for 17 high-quality security findings per day. Their triage, remediation, and patch deployment pipelines were built for a different volume. The result is a structural mismatch between disclosure velocity and remediation capacity that the CVD community has not yet developed standards to address.

Anthropic's approach to disclosure coordination at this scale required building infrastructure that did not previously exist. The 1,596 disclosures issued to date represent a filtered subset of the 10,000+ total findings. Anthropic applies an internal prioritization layer before external disclosure notifications go out, ordering disclosures by exploitability severity, the criticality of the affected software, and the potential for active exploitation.

The partner organization structure of Glasswing also changes the disclosure dynamic. Partner organizations have entered advance agreements with Anthropic that include awareness of and consent to ongoing vulnerability assessment. This differs from unsolicited CVD notifications where the vendor has no prior relationship with the researcher. Partners have designated security contacts, established communication channels, and baseline familiarity with Glasswing's disclosure process before the first notification arrives.

The nine confirmed public CVEs from Glasswing (FreeBSD NFS RCE, wolfSSL cert forgery, FFmpeg memory corruption, Linux LPE, VMM escape, browser JIT, V8 ACE, OpenBSD DoS, and smart contract vulnerabilities) represent the findings where the vendor patch has been released and the public disclosure window has opened. The remaining findings in the disclosure pipeline are still in various stages of vendor remediation.

A Glasswing disclosure notification carries different weight than a typical bug bounty submission. The finding has been validated by Mythos and reviewed by Anthropic's human security research team before it reaches your inbox. It includes a demonstrated exploit chain, not just a theoretical vulnerability description. The 90-day clock is running from the moment the notification is sent, not from the moment you acknowledge it.

Organizations that receive a Glasswing disclosure should treat it as a P0 incident immediately. The most common failure mode in handling high-quality external disclosures is routing them through normal ticket intake processes that prioritize based on queue position rather than severity. A Glasswing disclosure should bypass normal intake and go directly to your security response team lead.

The notification will include CVSS scoring and technical details. Your team should independently verify the finding in your environment rather than accepting the CVSS score as the final word on impact. Exploitability in a controlled research environment does not always translate directly to your specific deployment configuration, and there may be compensating controls already in place.

The operational response to an AI-discovered CVD notification differs from handling a traditional researcher report in a few important ways.

First, the finding quality is higher. You can generally trust the exploitability assessment more than you would a bug bounty submission from an unknown researcher. This means your triage process can weight the Anthropic-provided severity assessment more heavily and spend less time on basic exploitability validation.

Second, there may be multiple simultaneous notifications. If your organization is a Glasswing partner or runs software that Glasswing has assessed, you may receive more than one notification in a short window. You need a parallel-processing capability, not a serial queue.

Third, the disclosure timeline is non-negotiable in most cases. Anthropic has been consistent about the 90-day standard. Vendors who fall behind on patching should communicate proactively with Anthropic's disclosure team about patch status, not assume the window will extend silently.

The organizations best positioned to handle Glasswing-era disclosure volume are those that built their CVD intake process before they needed it. The core infrastructure requirements are not technically complex, but they require deliberate organizational investment that most companies have not made.

Your security response function needs a designated CVD intake contact with authority to escalate immediately to engineering and executive leadership. You need a documented severity assessment framework that does not rely solely on CVSS scores. You need a patch development and deployment process with a documented SLA for P0 findings. And you need a communication protocol for responding to disclosing parties with patch status updates at defined intervals.

For organizations running open-source software components (which is essentially every enterprise), you also need visibility into your software bill of materials (SBOM) down to transitive dependencies. Glasswing findings often surface vulnerabilities in foundational libraries (wolfSSL, FFmpeg, FreeBSD NFS) that appear as transitive dependencies in applications that do not obviously depend on them.

The regulatory and policy frameworks governing vulnerability disclosure were not designed for AI-scale discovery operations. CISA's coordinated vulnerability disclosure framework applies to federal agencies and critical infrastructure operators and provides guidance on handling disclosures, but does not address the specific operational challenges of receiving high-volume AI-discovered notifications.

ENISA, the European Union Agency for Cybersecurity, has published coordinated vulnerability disclosure policy guidance aligned with ISO/IEC 29147, which establishes baseline disclosure process standards. The standard does not address AI-generated disclosure volume specifically.

The UK AI Security Institute, which independently validated Glasswing's capabilities by testing Mythos against classified cyber ranges (Mythos became the first AI to solve both), is actively engaged with the policy implications of AI vulnerability discovery. The AISI's validation of Mythos capabilities adds regulatory credibility to Glasswing findings and signals that UK policy makers are treating this as a serious national security-relevant development.

The policy gap is real: current frameworks assume human-scale disclosure processes. Regulatory guidance specifically addressing AI-generated CVD volume, prioritization obligations, and vendor response timelines has not yet emerged. Organizations should expect CISA and ENISA guidance to evolve in response to the Glasswing precedent.

The CVE Program, administered by MITRE and funded by CISA, assigns CVE identifiers to publicly disclosed vulnerabilities. The program's capacity was built around human-scale discovery rates. Nine confirmed public CVEs from Glasswing represents only a small fraction of the 1,596 disclosures issued. The delta reflects both the patch cycle lag (findings are in the 90-day window, not yet public) and the CVE assignment infrastructure's capacity to process and publish CVE records.

As more Glasswing findings complete their 90-day windows and move toward public disclosure, the CVE assignment pipeline will face pressure it was not designed to handle. Vendors and security teams that use CVE identifiers as the primary trigger for patch prioritization will face increasing lag between disclosure and CVE assignment. The practical implication: organizations should not wait for a CVE to be assigned before patching. If your organization receives a private Glasswing disclosure or sees a vendor advisory referencing Glasswing research, treat it as patch-priority regardless of CVE status.

The full vendor response protocol and patch prioritization framework for handling AI-discovered CVD notifications at scale is available in the Mythos Brief.