Discrepancies Discovered in Vulnerability Severity Ratings

A new study this week is sure to raise more questions for enterprise security teams on the wisdom of relying on vulnerability scores in the National Vulnerability Database (NVD) alone to make patch prioritization decisions.

An analysis by VulnCheck of 120,000 CVEs with CVSS v3 scores associated with them shows almost 25,000 — or some 20% — had two severity scores. One score was from NIST, which maintains the NVD, and the other from the vendor of the product with the bug. In many cases, these two scores differed, making it hard for security teams to know which to trust.

High Rate of Conflict

Approximately 56%, or 14,000, of the vulnerabilities with two severity scores had conflicting scores, meaning the one assigned by NIST and the score from the vendor did not match. Where a vendor might have assessed a particular vulnerability to be of moderate severity, NIST might have assessed it as severe.

As one example, VulnCheck pointed to CVE-2023-21557, a denial-of-service vulnerability in the Windows Lightweight Directory Access Protocol (LDAP). Microsoft assigned the vulnerability a “high” severity rating of 7.5 on the 10-point CVSS scale. NIST gave it a score of 9.1, making it a “critical” vulnerability. Information on the vulnerability in the NVD provided no insight on why the scores differed, VulnCheck said. The vulnerability database is peppered with numerous other similar instances.

That high conflict rate can set back remediation efforts for organizations that are resource-strapped in vulnerability management teams, says Jacob Baines, vulnerability researcher at VulnCheck. “A vulnerability management system that heavily relies on CVSS scoring will sometimes prioritize vulnerabilities that aren’t critical,” he says. “Prioritizing the wrong vulnerabilities will squander vulnerability management teams’ most critical resource: time.”

VulnCheck researchers found other differences in the way NIST and vendors included specific information about flaws in the database. They decided to look at cross-site scripting (XSS) and cross-site request forgery (CSRF) vulnerabilities in the NVD.

The analysis showed the primary source — typically NIST — assigned 12,969 of the 120,000 CVEs in the database as an XSS vulnerability, while secondary sources listed a much smaller 2,091 as XSS. VulnCheck found that secondary sources were much less likely to indicate that an XSS flaw requires user interaction to exploit. CSRF flaw scores showed similar differences.

“XSS and CSRF vulnerabilities always require user interaction,” Baines says. “User interaction is a scoring element of CVSSv3 and is present in the CVSSv3 vector.” Examining how often XSS and CSRF vulnerabilities in NVD include that information provides insight into the scale of scoring mistakes in the database, he says.

Severity Scores Alone Not the Answer

Severity scores based on the Common Vulnerability Severity Scale (CVSS) are meant to give patching and vulnerability management teams a straightforward way to understand the severity of a software vulnerability. It informs the security professional whether a flaw presents a low, medium, or severe risk, and often provides context around a vulnerability that the software vendor might not have provided when assigning a CVE to the bug.

Numerous organizations use the CVSS standard when assigning severity scores to vulnerabilities in their products, and security teams commonly use the scores to decide the order in which they apply patches to vulnerable software in the environment.

Despite its popularity, many have previously cautioned against solely relying on CVSS reliability scores for patch prioritization. In a Black Hat USA 2022 session, Dustin Childs and Brian Gorenc, both researchers with Trend Micro’s Zero Day Initiative (ZDI), pointed to multiple issues like the lack of information around a bug’s exploitability, its pervasiveness, and how accessible it might be to attack as reasons why CVSS scores alone are not enough.

“Enterprises are resource constrained, so they typically have to prioritize which patches they roll out,” Childs told Dark Reading. “However, if they get conflicting information, they can end up spending resources on bugs that are unlikely to ever be exploited.”

Organizations often rely on third-party products to help them prioritize vulnerabilities and decide what to patch first, Childs notes. Often, they tend to give preference to the CVSS from the vendor rather than another source like NIST.

“But vendors can’t always be relied on to be transparent on the real risk. Vendors don’t always understand how their products are deployed, which can lead to differences in the operational risk to a target,” he says.

Childs and Bains advocate that organizations should consider information from multiple sources when making decisions around vulnerability remediation. They should also consider factors such as whether a bug has a public exploit for it in the wild, or whether it is being actively exploited.

“To accurately prioritize a vulnerability, organizations need to be able to answer the following questions,” Baines says. “Does this vulnerability have a public exploit? Has this vulnerability been exploited in the wild? Is this vulnerability being used by ransomware or APT? Is this vulnerability likely to be Internet-exposed?”