CVE-2023-5009: reconcile baseScore, baseSeverity and attackComplexity with the published vector

What is wrong

The CVSS v3.1 block in 2023/CVE-2023-5009.json disagrees with itself. One field describes one score and three describe another, so the record resolves to a different severity depending on which field a consumer reads.

field	value	implies
vectorString	CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N	8.2 HIGH
attackComplexity	LOW	9.6 CRITICAL
baseScore	9.6	CRITICAL
baseSeverity	CRITICAL	CRITICAL

Recomputing the stored vector under the FIRST CVSS v3.1 specification, section 8.1:

• AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N = 8.2
• the same metrics with AC:L = 9.6

AC alone separates the two readings, and the record currently asserts both.

Which value is correct

GitLab's own security release for 16.3.4 states the severity in prose and the score as a number, and both say 8.2 HIGH:

"This is a high severity issue (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N, 8.2)."

https://about.gitlab.com/releases/2023/09/18/security-release-gitlab-16-3-4-released/

The NVD copy of the CNA assessment renders the same conclusion:

cvssMetricV31 source cve@gitlab.com: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N -> 8.2 HIGH

https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2023-5009

Both agree on 8.2 and on HIGH, and 8.2 is only reachable with AC:H. So vectorString in this repository is the field that is right, and the other three need correcting.

Worth noting, because it is probably where this originated: the vector quoted in the release post itself reads AC:L beside the number 8.2, which is the same AC transposition in mirror image. The prose severity and the score are stated independently of that vector and agree with each other, which is what makes the direction unambiguous rather than a coin flip.

The change

Three fields, vectorString deliberately untouched:

-  "attackComplexity": "LOW",
+  "attackComplexity": "HIGH",
-  "baseScore": 9.6,
-  "baseSeverity": "CRITICAL"
+  "baseScore": 8.2,
+  "baseSeverity": "HIGH"

Why it matters beyond one record

This record is consumed by downstream scanners and by organisations prioritising remediation. A consumer that parses vectorString sees High; one that parses baseSeverity sees Critical.

CI validates records with ajv against the CVE JSON schema. Schema validation checks structure and cannot, by construction, detect that a vector string and its own decomposed metrics disagree, so this class of defect passes. I would be glad to follow up with a small cross-field consistency check if that is useful, but wanted to send the data correction on its own first.

How I verified it

Recomputed both candidate scores from the FIRST v3.1 specification rather than from a calculator, and checked the stored record against the MITRE CVE Services API and the NVD API directly rather than against a copy of either.