Published: 2026-07-04
Categories: Vulnerability Management
Key Takeaways
A consortium of 18 researchers led by MIT’s Shayne Longpre, with contributors from Stanford, Berkeley, Princeton, OpenAI, Anthropic, Google, MITRE, CISA, and Carnegie Mellon University’s CERT Coordination Center (CERT/CC), published FLARE-AI on June 30, 2026, an open-source flaw reporting system intended to replace today’s fragmented patchwork of AI vulnerability and incident intake forms with a single, interoperable, machine-readable submission path [1][6]. The paper is a peer-reviewed academic proposal rather than a CMU/SEI-issued standard: CERT/CC participated as one of 32 organizations consulted during development, and the effort runs alongside — rather than as part of — SEI’s own long-running program of coordinated AI/ML vulnerability disclosure work through its CERT Coordination Center and Artificial Intelligence Security Incident Response Team (AISIRT) [2][3]. Both efforts converge on the same diagnosis: AI flaw reporting today is scattered across at least a dozen incompatible intake systems, ranging from 7 to 53 required fields, few of which coordinate with one another or share information about issues that are already publicly known [1]. FLARE-AI’s design routes reports using a machine-readable taxonomy built on the OWASP Top 10 for LLM Applications and the AI, Algorithmic, and Automation Incidents and Controversies (AIAAIC) harm classification, letting a single submission reach affected developers, coordination bodies such as CERT/CC, and incident databases like the AI Incident Database and AI Vulnerability Database without the reporter re-filing separately with each [1]. For CISOs and security researchers who discover flaws in third-party AI systems, the practical near-term guidance is to treat FLARE-AI’s public intake at ai-reports.org as a supplementary reporting channel, monitor how vendors integrate with it, and align internal AI incident intake with the emerging vulnerability/hazard/incident distinctions the standard establishes, since regulatory reporting obligations such as the EU AI Act’s Article 73 serious-incident reporting requirement are converging on comparable triage categories [7].
Background
The market for AI systems has expanded far faster than the infrastructure for reporting when those systems fail. A security researcher who discovers a universal jailbreak, a data-poisoning vector, or a prompt-injection exploit today faces a bewildering set of choices: report to the model developer directly, file with a bug bounty platform, submit to a nonprofit incident registry, or escalate to a government coordination body — each with its own form, its own definition of what counts as reportable, and no guarantee that the other stakeholders who need to know will ever hear about it. The FLARE-AI team’s audit of 12 existing AI reporting systems found this fragmentation to be the rule rather than the exception: only three of the twelve allow anonymous submission, only nine permit any form of public disclosure, and just eight support any cross-organization coordination at all [1]. Only two systems in the entire sample — CERT/CC’s own intake and Google’s Vulnerability Reward Program — even track whether a reported issue has already been disclosed elsewhere, information the authors describe as critical for triage and prioritization [1]. The result is that good-faith reporters duplicate effort across multiple forms to reach every party who should be notified, while the parties who receive a report often have no visibility into whether the same flaw has already surfaced somewhere else.
This is not a new observation inside the coordinated-disclosure community. CERT/CC, the federally funded coordination body historically responsible for brokering vulnerability disclosure between researchers and vendors, published its own accounting of the problem in August 2024 in “Lessons Learned in Coordinated Disclosure for Artificial Intelligence and Machine Learning Systems,” drawing on its practical experience coordinating AI/ML vulnerability cases and concluding that existing disclosure norms, built for traditional software CVEs, translate awkwardly to AI systems where a “vulnerability” might be a jailbreak technique, a training-data poisoning method, or a bias-driven harm with no clean patch [3]. CERT/CC’s parent organization, the CMU Software Engineering Institute, formalized this concern institutionally in November 2023 by standing up the Artificial Intelligence Security Incident Response Team (AISIRT), described as the first dedicated AI-focused incident response function of its kind, tasked with protecting AI systems used by the Department of Defense and other federal agencies [2]. Led by technical director Lauren McIlvenny and operating within CERT/CC’s existing network of roughly 5,400 industry and research partners, AISIRT has since supported the response to more than 100 community-reported AI vulnerabilities, including LLM jailbreaks, the LeftoverLocals GPU memory-leak class of exploits, and prompt-injection attacks against deployed chatbots [2]. AISIRT and CERT/CC’s coordinated-disclosure research are the SEI-side half of this story, and CERT/CC’s practical experience running that intake was one of the inputs the FLARE-AI authors drew on when they consulted 49 experts across 32 organizations — including CERT/CC, CISA, MITRE, and the AI Incident Database — between June and August 2025 to shape the standard [1][2]. FLARE-AI itself, however, is an MIT-led academic and multi-stakeholder project accepted for presentation at ICML 2026, not a CMU/SEI work product, and readers should not conflate the two when citing either source [1][6].
Security Analysis
FLARE-AI’s architecture is built around resolving five recurring failure modes the authors identified across the systems they surveyed: poor discoverability of where to report, inconsistent scope and taxonomy definitions of what counts as reportable, mismatched information-collection burdens between minimal and maximal intake forms, an absence of machine-readable interoperability standards, and thin guidance for handling strict-liability content such as child sexual abuse material that may surface incidentally during a flaw report [1]. The system addresses discoverability with a centralized resource page indexing 15 existing reporting venues by organization type and flaw category, and addresses the collection-burden mismatch with adaptive form logic: a minimal six-field core path for reporters who want to file quickly, and an optional expanded path of up to 30 fields with conditional branching for reporters willing to provide fuller triage detail [1]. Every report a reporter submits — whether through the minimal or expanded path — is classified through three initial yes/no questions that determine whether it is treated as an incident (has it already caused harm), a vulnerability (could a malicious actor exploit it), or a case requiring the strict-liability workflow (does it involve CSAM), a triage structure the authors argue lets automated routing logic correctly send hazards and incidents to different downstream recipients than pure security vulnerabilities [1].
The interoperability layer is where FLARE-AI most directly targets the fragmentation problem: reports are generated as structured, machine-readable JSON-LD data compatible with the conventions used by CVE/CWE, the AI Vulnerability Database, and CERT/CC’s own coordination protocols, and the architecture is deliberately stateless, meaning a reporter can generate and download a complete report locally without any server ever storing it, then choose whether and to whom to disseminate it via API or email [1]. That design choice reflects a tension the authors are candid about: a centralized, unified AI flaw database would make triage and cross-referencing easier, but it would also create a single high-value target for attackers seeking a curated list of unpatched exploits, so FLARE-AI opts for reporter-controlled, optional routing over centralized storage [1]. For the harm and flaw taxonomies underlying the classification system, the authors adopted AIAAIC’s general-purpose harm taxonomy — chosen for being extensible and already used across multiple incident databases — and the OWASP Top 10 for LLM Applications for technical flaw categorization, on the reasoning that piggybacking on an existing, actively maintained taxonomy serves interoperability better than inventing a new one [1][5]. This is consistent with a broader pattern CSA’s own research on vulnerability data management has identified: legacy scoring and classification infrastructure such as CVE and CVSS, designed for conventional software, increasingly strains to represent the scale and heterogeneity of modern technology stacks, a strain that is more acute still for AI-specific flaw classes that do not map cleanly onto memory-safety or injection categories [4].
Two structural risks are worth flagging for organizations evaluating whether to integrate with FLARE-AI or a similar standard. First, the consultation process that shaped the taxonomy, while broad — spanning AI developers, coordination bodies, incident databases, academic researchers, and bug bounty platforms — skewed toward North American and European participants, and the authors acknowledge that global equity of access to the reporting infrastructure remains an open question, particularly for researchers in regions with less mature AI safety research ecosystems [1]. Second, the paper’s own risk section flags that machine-readable reporting infrastructure inherently advantages larger, better-resourced organizations that can build automated intake pipelines around it, potentially widening the gap between well-funded AI developers and smaller vendors who continue to rely on manual triage [1]. Neither risk is disqualifying, but both should inform how quickly and how uncritically organizations adopt FLARE-AI’s output format as a de facto standard before broader adoption data exists.
Recommendations
Immediate Actions
Security teams that maintain internal or public-facing AI systems should review FLARE-AI’s public demo and reporting flow at ai-reports.org to understand what a report routed to their organization through the standard would look like, and should confirm with their AI vendors whether they intend to register as a recipient organization within FLARE-AI’s routing logic [1][6]. Vulnerability disclosure and bug bounty program owners should cross-reference their existing intake forms against FLARE-AI’s five identified failure modes — discoverability, taxonomy consistency, field-count burden, machine-readability, and CSAM handling guidance — to identify where their own programs create unnecessary friction for good-faith reporters [1].
Short-Term Mitigations
Organizations running AI-enabled products should map their existing AI incident and vulnerability intake categories against FLARE-AI’s three-question triage structure (incident versus hazard versus vulnerability, plus the strict-liability CSAM branch), since aligning internal categorization now will reduce the translation burden if FLARE-AI or a similar interoperable format gains adoption as a routing standard among major AI developers and coordination bodies [1]. Teams should also begin tracking the EU AI Act’s Article 73 serious-incident reporting obligations, which take effect for providers of high-risk AI systems in August 2026 and impose reporting deadlines as short as two days for the most severe incidents, since the categorical distinctions FLARE-AI draws between hazards, vulnerabilities, and incidents map closely onto the causal and severity judgments Article 73 compliance will require [7].
Strategic Considerations
Chief information security officers overseeing AI governance programs should treat coordinated AI flaw disclosure as an emerging area requiring the same institutional investment historically given to traditional vulnerability management — a dedicated intake process, defined triage criteria, and named points of contact for both inbound external reports and outbound coordination with developers of AI systems the organization has integrated. The parallel emergence of FLARE-AI from the academic and AI-developer community and AISIRT/CERT/CC’s coordination infrastructure from the traditional cybersecurity establishment suggests the industry has not yet converged on a single authoritative body for AI flaw coordination, comparable to CVE’s role for conventional software; organizations should expect to interact with both channels for the foreseeable future rather than assuming one will supersede the other. Security leaders should also use this moment to formalize how their organization triages and escalates AI-specific flaws discovered internally, since a mature process for surfacing hazards and vulnerabilities before they become reportable incidents is a stronger risk posture than efficient external reporting alone.
CSA Resource Alignment
CSA’s Top Concerns With Vulnerability Data report is directly relevant background for evaluating FLARE-AI’s core premise: the report concludes that legacy vulnerability data infrastructure — CVE, CVSS, and the National Vulnerability Database — is straining under the scale and heterogeneity of modern technology stacks even before AI-specific flaw classes are considered, and explores supplementary scoring frameworks such as EPSS and SSVC as partial remedies. FLARE-AI’s decision to build a new, AI-native taxonomy and machine-readable reporting format rather than force AI flaws into existing CVE/CWE categories is a direct response to the same structural strain CSA’s report documents, and organizations already grappling with the vulnerability-data quality issues CSA identifies should view FLARE-AI as one candidate path toward better-structured AI flaw data specifically.
CSA’s The “AI Vulnerability Storm”: Building a “Mythos-ready” Security Program speaks to the urgency behind coordinated AI disclosure infrastructure from the opposite direction: as AI-driven tooling compresses the time between vulnerability discovery and exploitation across both conventional and AI-specific attack surfaces, the absence of a fast, interoperable channel for routing newly discovered AI flaws to every affected stakeholder becomes a more consequential gap [8]. FLARE-AI’s stateless, multi-recipient routing model is one concrete attempt to close that gap for the AI-specific flaw class that briefing describes as accelerating fastest.
Finally, CSA’s AI Controls Matrix (AICM v1.1) provides the governance baseline against which organizations can benchmark their AI threat-and-vulnerability-management and incident-response controls, including whether internal processes exist for triaging externally reported AI flaws and coordinating remediation with third-party AI vendors — the organizational capability that FLARE-AI and CERT/CC’s coordinated-disclosure work both assume as a prerequisite for effective participation in AI flaw reporting.
References
[1] Longpre, S., et al. “FLARE-AI: Flaw Reporting for AI.” arXiv:2606.31567, June 30, 2026.
[2] Carnegie Mellon University Software Engineering Institute. “AISIRT Advances National Security with Secure AI.” SEI, 2026.
[3] Householder, A. D., Sarvepalli, V. S., Havrilla, J., Churilla, M., Pons, L., Lau, S., VanHoudnos, N. M., Kompanek, A., & McIlvenny, L. “Lessons Learned in Coordinated Disclosure for Artificial Intelligence and Machine Learning Systems.” Carnegie Mellon University Software Engineering Institute, August 20, 2024.
[4] Cloud Security Alliance. “Top Concerns With Vulnerability Data.” CSA, November 2024.
[5] OWASP Foundation. “OWASP Top 10 for Large Language Model Applications (2025).” OWASP, 2025.
[6] FLARE-AI Project. “FLARE-AI: AI Flaw Reporting.” ai-reports.org, 2026.
[7] European Union. “Article 73: Reporting of Serious Incidents.” EU Artificial Intelligence Act, 2026.
[8] Cloud Security Alliance. “The “AI Vulnerability Storm”: Building a “Mythos-ready” Security Program.” CSA, April 2026.