CVE-2024-12345 was published with a CVSS score of 9.1. Security teams scrambled to assess their exposure. News articles called it "critical." Then the vendor disputed it, claiming it wasn't a real vulnerability.
This happens more often than you think. Let's talk about why CVEs get disputed and what it means for you.
How CVE Disputes Work
When a CVE is published, the affected vendor or other parties can dispute it through several mechanisms:
1. Direct Dispute
The vendor can contact the CNA (CVE Numbering Authority) that assigned the CVE and provide evidence that:
- The issue isn't a security vulnerability
- The affected versions are incorrect
- The severity is vastly overstated
- The issue was already fixed before CVE assignment
2. Public Rebuttal
Even if the CVE stands, vendors can publish advisories explaining their position. You'll see language like:
- "We do not consider this a security issue"
- "This requires physical access and is by design"
- "This is documentation, not a vulnerability"
3. REJECT Status
In some cases, CVEs get marked as REJECTED, meaning:
- The issue was duplicate of another CVE
- The report was fundamentally incorrect
- The CVE was assigned by mistake
- The vulnerability doesn't actually exist
Common Reasons for Disputes
1. "That's Not a Bug, It's a Feature"
Example: A researcher reports that an admin API allows file deletion. The vendor argues that's exactly what it's supposed to do, and if administrators misuse it, that's not a vulnerability.
Who's Right? Often, both have a point. The question is whether the design introduces unreasonable security risk.
2. Required Prerequisites Make It Unrealistic
Example: CVE-2024-XXXX describes a privilege escalation vulnerability. The vendor disputes it because:
- It requires physical access to the device
- The attacker must already have admin credentials
- Multiple security features must be intentionally disabled
The Gray Area: Defense-in-depth suggests we should fix these issues even if exploitation is difficult. But is it really a "vulnerability" if an attacker already controls the system?
3. Different Threat Models
Example: Researchers report memory disclosure via timing attacks. The vendor argues their threat model doesn't consider local attackers with the ability to run arbitrary code, as they've already won at that point.
Who's Right? Depends on context. In multi-tenant cloud environments or shared systems, these assumptions break down.
4. Documentation vs Implementation
Example: The documentation says a feature is disabled by default. A researcher discovers it's actually enabled. They report it as a vulnerability. The vendor says it's a documentation bug, not a security issue.
Impact: If users expect the feature to be off and configure their systems accordingly, they're vulnerable regardless of whether it's "documentation" or "code."
Famous CVE Disputes
Case Study 1: Intel SGX Vulnerabilities
Intel has repeatedly disputed or downplayed CVEs related to SGX (Software Guard Extensions), arguing that many researchers' threat models are unrealistic because they assume:
- Sophisticated attackers with kernel-level access
- Side-channel attacks requiring precise timing
- Attack scenarios that aren't practical
Researchers counter that SGX is explicitly designed to protect against privileged attackers, so kernel-level access should be in the threat model.
Takeaway: Threat model alignment matters. Be explicit about yours.
Case Study 2: WordPress "Vulnerabilities"
WordPress regularly disputes CVEs assigned to issues they consider:
- Plugin problems (not WordPress core)
- Intentional functionality being misused
- Issues requiring administrator access (who can already do anything)
Some are valid disputes. Others feel like splitting hairs.
Takeaway: Understand the boundary between different software components.
Case Study 3: Browser "Features" vs Vulnerabilities
Browser vendors and security researchers sometimes clash over whether tracking prevention bypass or fingerprinting techniques constitute "vulnerabilities."
Vendors: "These aren't security issues per our threat model." Researchers: "They undermine user privacy, which is a security property."
Takeaway: Security isn't just about remote code execution.
How to Handle Disputed CVEs
As a security professional, what do you do when a CVE is disputed?
1. Read Both Sides
Don't just trust the CVE or just trust the vendor. Read:
- The original CVE description
- The vendor's dispute or advisory
- Any technical analysis from independent researchers
- Discussion in security communities
2. Evaluate For Your Environment
Ask:
- Does this issue matter in our specific configuration?
- Does our threat model include the attack prerequisites?
- Are we relying on the disputed behavior for security?
3. Apply Defense in Depth
Even if the vendor is technically correct that something isn't a vulnerability, consider:
- Would fixing it reduce risk anyway?
- Is there a low-cost mitigation available?
- Could future changes make this more exploitable?
4. Document Your Decision
Record why you're patching or not patching disputed CVEs. Future you (or your successor) will thank you.
The Bigger Problems
CVE disputes reveal systematic issues:
1. Misaligned Incentives
- Vendors want to minimize security issue counts (looks bad to have lots of CVEs)
- Researchers want recognition (CVE assignments look good)
- CNAs want accurate data but may lack full context
Nobody's really incentivized to agree.
2. No Clear Vulnerability Definition
What is a vulnerability? The community doesn't have a universally accepted definition. We generally know it when we see it, but edge cases are contentious.
3. Public Pressure
Once a CVE is public and covered by media, it's hard for vendors to downplay it without looking defensive - even when they're right. This incentivizes escalation rather than resolution.
4. CNA Variability
Different CNAs have different standards for what qualifies as a CVE. Some are strict, some are permissive. This leads to inconsistency.
What Changes Might Help
The community has proposed various improvements:
- Standardized Dispute Process: Clear mechanism and timeline for disputes
- Public Evidence: Require both sides to present technical evidence publicly
- Independent Review: Have neutral third parties assess disputes
- Clearer Severity Thresholds: Better guidelines for what qualifies as a vulnerability
None of these are easy, and all have trade-offs.
Practical Advice
For vulnerability management:
-
Don't Auto-Patch Based on CVSS Alone Even "critical" CVEs might not affect you.
-
Follow Vendor Advisories They often provide crucial context missing from CVEs.
-
Understand Your Threat Model Know what attacks you're defending against.
-
When in Doubt, Patch If you can easily mitigate a disputed CVE, why not?
-
Build Relationships Connect with security researchers and vendor teams. Context matters.
The Bottom Line
CVE disputes aren't just bureaucratic quibbles. They reveal fundamental tensions in how we think about security:
- What constitutes a vulnerability?
- Whose threat model matters?
- How do we balance disclosure with accuracy?
As defenders, we need to:
- Think critically about CVEs rather than treating them as gospel
- Understand the nuance behind security issues
- Make risk-informed decisions for our specific environments
Not every CVE is critical. Not every dispute is valid. The truth is usually somewhere in the middle.