CVE-2023-3399 and CVE-2023-3932: reconcile CVSS fields with the published vectors

Two more records in this repository where a CVSS v3.1 field contradicts the vector GitLab published in its own security release. Same class as !77, found by the same check. Three lines across two files, and no vectorString is modified.

CVE-2023-3932: baseScore and baseSeverity

field	stored	implies
vectorString	CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N	8.2 HIGH
all decomposed metrics	AV:N AC:H PR:L UI:N S:C C:H I:H A:N	8.2 HIGH
baseScore / baseSeverity	5.3 / MEDIUM	disagrees with both

The 16.2.2 security release states it directly:

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

https://about.gitlab.com/releases/2023/08/01/security-release-gitlab-16-2-2-released/

The published vector is character-identical to the stored one, and the canonical issue #417594 carries severity::2. Four independent signals say 8.2 HIGH and one says 5.3 MEDIUM.

-  "baseScore": 5.3,
-  "baseSeverity": "MEDIUM"
+  "baseScore": 8.2,
+  "baseSeverity": "HIGH"

CVE-2023-3399: decomposed scope

field	stored	implies
vectorString	CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N	8.5
baseScore	8.5	consistent with S:C
scope	UNCHANGED	7.1

Recomputing under the FIRST v3.1 specification: those metrics with S:C give 8.5, and with S:U give 7.1. The 16.5.1 release post publishes the vector identically to the record, including S:C:

https://about.gitlab.com/releases/2023/10/31/security-release-gitlab-16-5-1-16-4-2-16-3-6-released

-  "scope": "UNCHANGED",
+  "scope": "CHANGED",

One thing I am deliberately NOT changing here. That same release post describes this issue as "Low" in its severity column and as a "medium severity issue" in the prose, while quoting 8.5, which is High. I have not touched baseScore or baseSeverity on this record, because the published severity wording does not settle which of those is intended and I would only be guessing. The scope field is different: it contradicts a vector that GitLab published verbatim, so the direction is not in doubt. Happy to follow up separately on the severity wording if that is useful, but it seemed wrong to fold a guess into a change that is otherwise checkable.

How I verified this

Recomputed both candidate scores from the FIRST v3.1 specification rather than from a calculator, fetched the records from the MITRE CVE Services API directly, read the two release posts rather than search summaries, and checked the canonical GitLab issue labels. On !77 the same check initially pointed the wrong way and the release post corrected it, so I treated the published post as the anchor here rather than the record's internal majority.