A CVE ID Is Not a Confirmed Vulnerability

“It has a CVE number, so it is a confirmed vulnerability and we have to treat it as one.”

Let me stop you there, before the ticket gets a severity, an owner and a deadline for a flaw nobody has shown exists.

A CVE ID is not a confirmed vulnerability.

A CVE ID records that somebody asked for an identifier.

It records that a numbering authority with scope granted the request.

It records a date, a description, and whatever references came with it.

What it does not record is a verdict.

Nothing in the identifier says anyone proved the flaw real before the number existed. When somebody later says it isn’t, the program’s answer is usually a status called DISPUTED, and the record stays live.

About 85% of records that reach DISPUTED simply stay there.

So the identifier in your queue is a claim with a name.

Sometimes a very good claim. Usually an uncontested one.

But a name is not a confirmation, and the status field exists precisely because some of those claims are wrong.

1. “But MITRE Approved the ID.”

MITRE approved the request.

That is a different act from confirming the flaw.

MITRE created the CVE concept in 1999 to stop vendors and scanners naming the same flaw differently. It runs the program under a contract with the US Department of Homeland Security, awarded through CISA.

It is the Top-Level Root for the general namespace. It publishes the CNA Rules. It adjudicates disputes that reach the top of its hierarchy.

And through its CNA of Last Resort role, it also assigns IDs itself when no other numbering authority has scope over a product, or a vendor won’t act.

Referee and participant, in the same organization.

Below it sit roughly 484 CVE Numbering Authorities across about 40 countries as of early 2026, of which 365 actually assigned an ID in 2025. CISA runs a second Top-Level Root, since September 2020, for industrial control systems and medical devices. ENISA became a CNA in January 2024 and a full Root in November 2025.

That is a federated issuing system.

Not a laboratory.

The path an ID takes is fixed by scope. The Supplier CNA, the vendor or maintainer of the affected product if it holds CNA status, gets the first opportunity to assign, and the first opportunity to decline. If there is no supplier CNA, or it declines or doesn’t answer, the request passes to another CNA with appropriate scope, and ultimately to a CNA of Last Resort.

An independent researcher with no CNA relationship of their own goes to the vendor’s CNA if one exists.

If not, to MITRE.

That is the route a lone reporter actually uses, and it is the route that produced CVE-2023-52071.

In late December 2023, an anonymous reporter asked MITRE for a CVE covering what they described as a security flaw in curl.

MITRE approved it.

The record went public on 30 January 2024.

curl’s maintainer, Daniel Stenberg, examined the claim and concluded it was not a vulnerability at all: the underlying assertion was factually wrong, and in his account easy to show as wrong.

The ID existed anyway. It had been approved anyway. It was public anyway.

“MITRE approved it” tells you who issued the number. It tells you nothing about who checked the bug.

2. “But It Is in the Scanner Feed With a Severity.”

Of course it is.

Feeds ingest what is published.

The National Vulnerability Database takes in every published CVE Record and adds its own enrichment on top. NIST has no role in assigning identifiers and no seat in the CNA hierarchy. It cannot assign an ID, and it cannot reject one.

So the presence of a score tells you somebody processed the record.

It does not tell you the program has stopped arguing about it.

A DISPUTED record is, by design, still live and searchable. That is the point of the status: it flags, to anyone reading the record, that the claim is contested and the reader should check the references or contact the vendor before treating it as established.

Now look at what your pipeline does with that flag.

If the scanner-to-ticket path carries the ID, the product match and the number, and drops the status on the floor, the one field the program provides for “this might not be real” never reaches the person deciding priority.

The feed didn’t confirm anything.

Your ingestion stripped out the part that said it hadn’t.

Whether a real flaw is present and reachable in your environment is a further question again, and a separate argument. This one is earlier: whether there is a flaw at all.

3. “But the Vendor Would Have Had It Rejected If It Were Bogus.”

The curl record is the test of that belief, and it fails it.

Stenberg asked MITRE to reject CVE-2023-52071 outright.

MITRE declined to reject it immediately. It marked the record DISPUTED instead.

The reason it gave, preserved in Stenberg’s public account, was procedural, not technical:

“If we transfer, and Curl REJECTS, then the reporter will likely come back to us and dispute which will provide some confusion for the public.”

Weigh that.

The top of the hierarchy chose a contested-but-live record over a fast reversal, because a reversal might itself be disputed.

On 23 February 2024, MITRE changed the status to REJECTED.

Stenberg found out from a public discussion thread, not a notification.

From publication on 30 January to rejection on 23 February is 24 days: one remaining day of January plus 23 of February. For the whole of that window, a record the maintainer considered plainly wrong sat in the public namespace with a live ID.

And curl is the favourable case.

It had a maintainer willing to argue publicly, a clear technical rebuttal, and an eventual REJECTED.

The base rate is not that.

Rejection runs through the same hierarchy that assigned the ID. A contested assignment is raised under the CVE Record Dispute Policy with the responsible CNA, escalates to its Root, and ends at the Top-Level Root: MITRE for the general namespace, CISA for industrial control and medical devices.

There is no independent appeal outside that chain.

A vendor’s objection is one party’s position. It is not a reset button.

4. “But a Disputed CVE Will Be Cleaned Up Soon Enough.”

It usually won’t.

Keep the two statuses apart, because they make different claims.

DISPUTED: a party, typically the vendor but sometimes another CNA or a researcher, disagrees that the reported issue is a vulnerability. The record stays live. It is a flag, not a verdict.

REJECTED: the ID should no longer be used. Most often it duplicates another ID, was withdrawn by the requester, was assigned to something that turned out not to be a security issue, or was an administrative error. The record is not deleted. It stays on the CVE List with a REJECT-state explanation, so anyone meeting the ID in an old report can learn it no longer applies.

Now the rates.

Rejected records ran to 603 of 31,103 published records in 2023, and 737 of 38,912 in 2024. Both are about 1.9%. In 2025 it was 1,648 of 40,480, about 4.1%.

Most of that is housekeeping, not correction. Of 2025’s rejections, roughly 94% were caught before the record ever reached PUBLISHED: a CNA reserved an ID, found internally it was a duplicate or not a real issue, and withdrew it. About 5% were published and later rejected.

The disputed-then-rejected path, curl’s path, accounted for 18 records in 2025.

Against 1,648 rejections that is about 1.1% (18 ÷ 1,648).

And of records that reach DISPUTED at all, roughly 85% stay disputed. Neither confirmed nor withdrawn.

So DISPUTED is not a queue toward resolution.

It is a permanent asterisk, and the program is comfortable leaving it attached indefinitely.

A triage process that waits for the asterisk to go away is waiting on something that, roughly 85 times in 100, doesn’t happen.

5. “But the Researcher Has a Reputation to Protect.”

Some do.

The one behind CVE-2023-52071 was anonymous.

An anonymous request carries no personal reputation, and the CNA of Last Resort path exists precisely for reporters with no vendor relationship.

Now take the named researcher, because the incentive is real and worth stating plainly.

For an independent researcher, a named CVE is credit. Credit becomes a public writeup, a reputation, consulting work, bounty income. That sits alongside the other thing a researcher wants, which is to see the bug actually fixed.

Both are legitimate.

Neither is a confirmation mechanism.

Say the next part carefully, because it is an inference rather than a recorded fact: an incentive that rewards a named identifier will produce some requests for identifiers that don’t hold up. The incentive is documented. Contested requests are documented. Nobody has shown the first causing any particular instance of the second, and that includes curl’s.

The intermediaries don’t close the gap either.

HackerOne reports over 1,950 enterprise programs and more than 580,000 validated reports. Platforms triage for validity and duplicates, and they are commercially aligned with the vendors who pay the subscription, not neutral coordinators.

CERT/CC is the neutral party. It has no product to protect and no bounty budget. It also has no mechanism to compel anybody to do anything, only reputational pressure.

And when researchers and vendors do collide, nothing arbitrates.

In January 2015 Google’s Project Zero disclosed a Windows 8.1 privilege-escalation flaw on its policy deadline, two days before Microsoft’s scheduled patch. Microsoft’s Chris Betz called it “less like principles and more like a ‘gotcha’.” Neither side moved.

In 2013 Yahoo answered High-Tech Bridge’s cross-site-scripting reports with a $12.50 company-store discount code per bug, and changed its program only after public backlash.

In 2017 DJI offered Kevin Finisterre $30,000, and the negotiation collapsed over the legal terms. He declined, published, and DJI revised its bounty terms afterwards.

Public pressure. Later policy change. Or nothing.

That is the environment reports come out of: incentives, deadlines and no referee. The CVE ID is issued downstream of all of it, not above it.

6. “But Setting Aside a CVE Will Look Bad in the Audit.”

Setting it aside with no record will.

Setting it aside with a record is the defensible position.

The program itself works this way. A REJECTED record is kept visible, with a reason, specifically so that someone encountering the ID later can see why it no longer applies.

Do the same.

For a DISPUTED record you accept: note that it was disputed, what the supplier said, what the references show, and why you are treating it as real anyway.

For one you set aside: the same, in the other direction.

Either decision can be reviewed.

What can’t be reviewed is a finding that vanished because a filter dropped it, or a remediation sprint spent on a record the maintainer publicly called wrong, with nobody having read the maintainer’s statement.

The audit risk is not the decision. It is the absence of a reason.

7. No, This Does Not Mean CVEs Are Unreliable.

They aren’t, as a class.

Most CVE records are uncontested. A CNA assigns, publishes, and nobody argues.

Even most rejections are the system catching its own errors before publication, which is the process working.

Nor does a vendor’s DISPUTED flag settle anything in the vendor’s favour. DISPUTED means one party disagrees. That party has a product to protect and wants control over its own disclosures. A dispute is one position, not a finding, and a real flaw can sit under a vendor’s objection.

So do not build a filter that drops every disputed record.

That just replaces one unexamined assumption with another.

The correction is narrower.

Record status and the evidence behind it are triage inputs. They are not noise to be normalized away before prioritizing.

8. What You Should Actually Do

Ingest record status. Carry PUBLISHED, DISPUTED and REJECTED through from the source to the ticket. If a feed or scanner drops the field, that is a defect in your pipeline.

Suppress REJECTED IDs from findings. The program has said the ID should not be used. Keep the rejection reason where someone can find it when the ID turns up in an old report.

Route DISPUTED records to a reviewer. Someone reads the references and the supplier’s statement before the record is prioritized. Not after the sprint.

Record which CNA assigned each ID, and whether it is the supplier. A supplier-assigned ID and one granted through the CNA of Last Resort on a request the supplier contests are different evidence. Your records should say which one you are looking at.

For software you publish, evaluate CNA status for your own scope. It gives you the first opportunity to assign, and to decline, before a record reaches PUBLISHED. curl obtained CNA status in mid-January 2024. CVE-2023-52071, which MITRE had already granted on an earlier request, still went public on 30 January. The status governs what comes next, not what is already in flight.

Write down the rationale whenever a disputed CVE is accepted or set aside. Evidence read, supplier position, decision, owner, date.

And treat the numbers here as dated. CNA counts, rejection rates and platform statistics move every year. The structure behind them moves much more slowly.

9. The Actual Model Is Not Complicated.

A CVE ID answers: did a numbering authority with scope grant a request for an identifier?

The assigning CNA answers: who made that decision, and was it the supplier?

Record status answers: is anyone contesting the claim, and has the program withdrawn it?

Only the evidence answers: is the reported behaviour actually a vulnerability?

The first three are metadata about an assignment decision.

The fourth is the one your priority depends on.

Use CVE IDs. They are what make an advisory, a scanner and a ticket talk about the same thing.

Read the status.

Read the references.

Read what the supplier said.

Then decide, and write down why.

An identifier documents that somebody asked and somebody granted.

Whether the flaw is real was never the question the number answered.