After two months of cutbacks by the National Institute of Standards and Technology (NIST) on CVE enrichment, new research reveals some concerning trends that could make it harder for security teams to prioritize vulnerabilities.
In April, the NIST began dramatically reducing the number of CVEs that received “enrichment,” or additional analysis, from the agency for its National Vulnerability Database (NVD). The shift was due to a severe backlog in submitted vulnerabilities, which led the NIST to prioritize flaws that, for example, were under exploitation or were featured in products used by the federal government.
As a result of the reduction, fewer vulnerabilities now have additional details such as CVSS scores from the NIST. At the time of the NIST’s announcement, experts expressed concern that the lack of enrichment could create issues for organizations that rely on the NVD for guidance in vulnerability management.
Those concerns were well-founded, according to research from cybersecurity startup Volerion. The company analyzed two months of vulnerability data since NIST’s cutbacks and highlighted several concerning trends that could complicate end-user organizations’ efforts to identify, prioritize and remediate vulnerabilities.
It’s not just a lack of coverage for many CVEs, says Volerion co-founder Ruben Bos. “They’re also wrong on the conclusions a lot of times.”
CVE Coverage Gaps, Delays
Between April 15 and June 15, Volerion analyzed all 13,441 non-rejected CVEs that were published to the NVD. Of that number, the research team found that more than half of those flaws, 8,342, were prioritized for enrichment by NIST.
However, Volerion also found that just 6,759 vulnerabilities actually received NIST enrichment, which left 1,583 published CVEs that remain unanalyzed. Additionally, only 2,645 of the flaws that were enriched also received a NIST CVSS vector. According to Volerion, the NIST likely skipped over CVEs that had already received a CVSS score from a CVE Numbering Authority (CNA), which are organizations such as cybersecurity companies and technology vendors that are authorized to assign and publish CVE IDs for specific vulnerabilities.
“However, CNA vectors are produced by many different organizations, each with varying levels of expertise, bias, and consistency,” Volerion’s blog post states. “This is why NIST vectors were in demand. They came from an independent and, on paper, knowledgeable and reputable source.”
Currently, there are more than 500 CNAs in the CVE Program, which is overseen by Mitre Corp., an organization that has also struggled recently amid funding uncertainty for the program. And because multiple CNAs can publish a CVE and CVSS scores for the same flaw, the process can sometimes lead to duplicate entries, conflicting analyses, and even disclosure disputes.
Volerion also found that timeliness was an issue for NIST enrichment. While the median time-to-analysis for vulnerabilities in each month was relatively short — nearly four days in May — the research team found many vulnerabilities each week were still listed as “Awaiting Analysis,” and therefore were exempt from the time-to-analysis metrics.
The researchers found bottlenecks emerging when the number of published CVEs per week spiked and warned that with rising vulnerability reports (as evidenced by Microsoft’s record-setting Patch Tuesday this month), the NIST will likely fall behind even further.
Volerion’s analysis found a significant number of CVEs slated for NIST enrichment each week were either deferred or still awaiting analysis. SOURCE: Volerion
“It can very slow, depending on the time frame you measure,” Karel Knibbe, Volerion co-founder, says of the enrichment process. This can cause problems for organizations that need to make quick decisions about which CVEs need to be prioritized and patched.
CVE Inaccuracies, Score Discrepancies
Perhaps the biggest issue with the reduction in enrichment is that it deprives end-user organizations of a vulnerability assessment and CVSS score from an independent third party. Volerion said this is particularly problematic for cloud service providers (CSPs) within FedRAMP, which requires CSPs to use the NIST’s CVSS score in determining their risk.
But there are also accuracies issues, according to the report. With no CVSS scores from the NIST, end users are left to rely on scores from CNAs, which are sometimes biased, Bos says. A cybersecurity company, for example, may want to inflate the severity of a CVE for higher bug bounty payouts or marketing purposes, or a technology vendor might want to lower the score for a flaw in their product. “Some CNAs are just rubbish because they don’t understand [the vulnerability] on a technical level, and there are a lot of cases where they just want the celebrity vulnerability,” he says.
Additionally, Volerion found accuracy issues with NIST’s own analyses. The company ran thousands of CVEs over the two-month period through its own vulnerability intelligence platform and found scoring discrepancies, vector disagreements and missing context.
The researchers determined that the most common disagreement between Volerion’s analysis and NIST’s assessment was in the attack complexity category. In about of third of all disagreements, the company found that NIST had rated a CEV’s attack complexity as “AC:L” for low, whereas Volerion determined the complexity to be AC:H or high. The researchers observed many cases, the NIST analyses missed that that privileges or user interaction were required for exploitation.
Volerion cited an example of a case where the discrepancies were considerably large. CVE-2026-8856, a denial of service flaw in IBM HTTP Server 8.5 and 9.0, received a critical severity rating with a 9.1 CVSS from NIST, while IBM determined it was a medium-severity flaw with a 7.7 score.
But Volerion’s score was even lower — a medium-severity 4.4 — based on several vectors. For example, the researchers determined that because a vulnerable server must be configured to give external threat actors write access, CVE-2026-8856 should be listed as AV:L (local attack vector) and PR:H (high privileges required) rather than AV:N (network attack vector) and PR:N (no privileges required).
Not all CVE disagreements Volerion analyzed involved assessments or scores that were too high. Bos says there are probably cases in the data set where the opposite occurred, but the underlying issue is the same — conflicting assessments and scores can create confusion for organizations about both the severity and technical nature of a flaw.
NIST Hampered by CVE Volume, Data Issues
The NIST’s cutbacks on enrichment were supposed to help the agency alleviate the burden of analyzing an ever-growing number of vulnerabilities and allow it to concentrate on high-priority CVEs. But Volerion found the NIST is still struggling under the new approach with delayed enrichment and inaccuracies.
Part of the issue, Knibbe says, is that NIST’s system for selecting CVEs for enrichment is likely an automated one that pulls data in from different sources such as the Cybersecurity and Infrastructure Security Agency’s (CISA) Known Exploited Vulnerabilities (KEV) catalog. But Kribbe notes, as many organizations have pointed out over the years, that CISA often makes mistakes. The agency misses some flaws that should be in the catalog, while others are added prematurely, and updated KEV listings aren’t publicized. And because of the volume of disclosed vulnerabilities, the NIST likely lacks the bandwith to manually review and select each flaw for enrichment.
“It’s bad layers built on bad foundations,” Kribbe says.
On the positive side, Bos says Volerion is assisting CISA with its Vulnrichment project, which is a public GitHub repository of CISA-enriched CVEs designed to give organizations additional context and insight into notable vulnerabilities. Volerion also released an NVD-compatible API for CVEs, which provides enrichment via the company’s platform for CVSS 3.1 and CVSS 4.0 vectors, as well as other contextual data.
In the meantime, Kribbe and Bos urged organizations to institute a vulnerability prioritization system that doesn’t rely only on CVE severity and CVSS scores and instead uses the available vectors, metrics and analysis data to get as much context as possible.
“I think the ideal situation would be to have your own decision tree and then plug all those metrics and values into the decision tree and have an outcome that works well for your organization,” Kribbe says.
No responses yet