Proposal: Define CVE assignment SLAs for publicly disclosed and actively exploited vulnerabilities

[yogeshnmittal]

The global CNA Rules currently lack a defined timeline or SLA for assigning CVEs to vulnerabilities that are already public and actively exploited.

Background
CNA Rule 4.2.1.2 states that "if a CNA responds within 72 hours that it will not assign a CVE ID to a vulnerability, or does not respond within that window, the Root must make a vulnerability determination". However, some CNAs acknowledge the vulnerability within 72 hours but delay assigning the CVE ID (e.g. until their final fix or remediation is ready). This loophole exists because Rule 4.2.7 states that CNAs should assign CVE IDs to vulnerabilities, but it completely omits a timeline or deadline for execution

The Bottleneck & Ecosystem Impact
While this delay is acceptable for embargoed or low-profile bugs, it creates a severe bottleneck for the wider security ecosystem when the vulnerability is already public and actively being exploited. Furthermore, enterprise scanners and machine-readable vulnerability feeds depend strictly on the CVE ecosystem. Without an assigned CVE ID, organizations and end users remain completely blind to known public risks.

Proposed Action for SPWG
As a minimum I request the SPWG review and update the CNA Rules to establish a firm deadline (e.g. 72 hours from acknowledgment) for CVE assignment strictly when a) the vulnerability is publicly disclosed and b) functional exploit or PoC is publicly available.

Defining this SLA will empower defenders and vendors to protect users faster, provide clarity for CNAs, and drastically reduce the need for administrative escalations to MITRE and other Roots.

[sashalevin]

This gets framed as a CNA acknowledging an issue and then sitting on the ID until a fix is ready. That's not usually what's happening. Volunteer CNAs are already working through backlogs of hundreds of public issues that come with a reproducer, plus a few hundred more without one, and all of them are public.

A forced SLA doesn't make anyone able to triage faster. The thing that's actually scarce here is domain expertise. Deciding whether something is a real vulnerability, what its scope is, and whether it warrants an ID takes people who understand the code deeply, and there are very few of them. You can't mandate that small group into producing correct assignments faster, and rushing them produces worse IDs, not more of them.

So all an SLA can really do is reorder the queue, and that's the part I'd push back on hardest. What this really comes down to is a big vendor wanting to cut the line for whatever issue is hyped up that week, ahead of the hundreds of public issues already sitting in front of it. That doesn't help users. It just shuffles the same limited expertise around and adds coordination overhead on top. The blind spot doesn't shrink, it moves to whoever didn't get to do the lobbying.

It's also worth being clear that having a Root or CNA-LR step in and assign CVEs inside another CNA's scope is not a free shortcut. Those assignments are made without the scoped CNA's domain knowledge, so they routinely need scope corrections, disputes, merges, and other cleanup afterward, and all of that lands back on the very CNA you were trying to route around. You end up adding to their workload, not removing it, which makes them slower over the longer term rather than faster.

[zmanion]

From SPWG 2026-06-10:

In 4.2.1.2, if a Supplier CNA (having most appropritate scope) responds even basically that they are investigating a report, none of the conditions are met, so this CNA is now holding up assignment and publication, there is no deadline.

The Program understands and has no intention to add pressure to scarce and constrained resources, such as Linux kernel experts or any Supplier CNA who naturally needs time to analyze and respond to a suprising vulnerability report (like a 0-day drop or EITW), or really any public report, as in the Linux kernel example above. The Linux kernel CNA has scope and first refusal and is or will be handling all of those reports, the Program generally should not interfere. That said, there could be urgent cases in which it is better to assign and publish quickly, even before fixes and additional analysis have occurred.

Another case is "artificial" delays, such as Synology publishing CVE Records 90 days after publishing advisories and fixes. This does not benefit the Program.

There was discussion of a new service that collects community interest in wanting a CVE ID and Record for some vulnerabilities, perhaps a way to assess urgency and importance, possibly based on reputation, as a way for a CNA-LR to better decide when to act, possibly overriding a Supplier CNA who is "holding up" action.

The RBP policy might impose timelines, if so, review and consider those.

CNAs (SHOULD? MUST?) NOT impose intentional and artificial delays between Public Disclosure and publishing a CVE Record.

For Publicly Disclosed and possibly "urgent" vulnerabilities there may be more value in publishing a CVE Record quickly and adding (correcting) information as it becomes available, even transferring the Record to the (probably Supplier) CNA with most appropriate scope. Or the assignment and Record can be disputed or rejected.

[zmanion]

A related issue, 4.2.1.2 currently requires a Root and CNA-LR to act when first refusal is exercised:

...then an appropriate Root MUST make a Vulnerability determination

Depending possibly on a resolution to #27, other CNAs may be permitted to act at this point.

[zmanion]

Does 4.5.1.5 apply if a CNA says they are investigating, implies that they will publish, then does not act "in time?"

4.5.1.5 In exigent circumstances, for Publicly Disclosed Vulnerabilities, when a CNA with appropriate scope has not published a CVE Record, an appropriate TL-Root MAY direct an appropriate CNA-LR to publish a CVE Record. Ownership of the CVE Record SHOULD be transferred.

[gregkh]

What exactly is "in time"?

[yogeshnmittal]

Great inputs, Art. And like Greg asked, we need clarity on what is "in time". A few technical clarifications on why the existing rules don't quite cover this loophole:

• Rule 4.2.1.2 only kicks off if a CNA explicitly refuses to assign a CVE, or completely fails to respond within 72 hours. In the scenario I am highlighting, the CNA does respond within 72 hours (e.g., stating "we are investigating"), which successfully pauses the clock indefinitely without an actual assignment ever occurring.
• Rule 4.5.1.5 allows a TL-Root to direct a CNA-LR to publish a record in exigent circumstances, but it is an optional fallback ("MAY") without an objective operational trigger or defined timeline.

My proposal is strictly focused on establishing a predictable upstream baseline for assignment when a vulnerability is a) publicly disclosed and b) actively exploited or has a functional PoC available.

I really appreciate the SPWG's discussion on separating valid analysis delays from artificial delays. However, to protect end users and the community at large, we need a clear timeline that empowers CNA-LRs to step in and assign CVE IDs under these specific high-risk criteria so downstream scanners aren't left blind.

[gregkh]

Note, be careful about requiring that if a PoC is in public to force a creation of a CVE to be published. That will cause some projects (like Linux) to be forced to publish hundreds of CVEs without any fixes present due to the public reports of fuzzers and other tools that are creating and "publishing" bug reports at very high rates.

Closed source projects have the luxury that their bug reports are normally private, not public. If you force open source projects to publish CVEs whenever a public bug report happens that meets the definition of a CVE, the ecosystem will be flooded with thousands of "unfixed" CVEs that end users and CNAs will have an impossible time to track and monitor over time.

[sashalevin]

Agreed there's no good reason for an artificial delay. If a vendor has already published its own advisory and fix, sitting on the Record after that helps no one, and a rule targeting that is reasonable.

Rule 4.5.1.5 is about exigent circumstances, and exigent means unforeseen and urgent. A publicly disclosed bug with a PoC working its way through the queue is neither. It's the normal, expected flow, not an emergency, so it isn't the case 4.5.1.5 was written for. If the whole CNA team gets hit by a bus, sure, that's the case, go invoke it.

The LR in CNA-LR stands for last resort, not "step on the scoped CNA's toes." The role exists for the gaps: no CNA has scope, the vendor is gone, or the scoped CNA declines. A CNA that has scope and is actively working its queue is the opposite of a last-resort situation, so routing around it isn't what the role is for.

And it doesn't even speed anything up. An assignment made without the Supplier CNA's domain knowledge comes back needing scope fixes, merges, and disputes, all of which land on that same CNA. You add to their workload, so the practical result is more delay for them, not less.