cvelistV5 icon indicating copy to clipboard operation
cvelistV5 copied to clipboard

Clarification on handling multiple cvssV4_0 entries in the metrics array

Open ncrocfer opened this issue 8 months ago • 6 comments

Hi MITRE team,

I'm working on a project (https://github.com/opencve/opencve) that consumes data from the CVE 5.0 JSON format, and I’d like to clarify something regarding the structure of the metrics array.

In some CVEs — for example, CVE-2025-0123 — there are multiple objects in the metrics array that contain the same cvssV4_0 key. In this specific case, two entries are present and I don't know which one to choose:

      "metrics": [
        {
          "cvssV4_0": {
            "Automatable": "NO",
            "Recovery": "AUTOMATIC",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "LOW",
            "attackRequirements": "NONE",
            "attackVector": "LOCAL",
            "baseScore": 5.9,
            "baseSeverity": "MEDIUM",
            "privilegesRequired": "HIGH",
            "providerUrgency": "AMBER",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "HIGH",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "valueDensity": "DIFFUSE",
            "vectorString": "CVSS:4.0/AV:L/AC:L/AT:N/PR:H/UI:N/VC:L/VI:N/VA:N/SC:H/SI:N/SA:N/AU:N/R:A/V:D/RE:M/U:Amber",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "LOW",
            "vulnIntegrityImpact": "NONE",
            "vulnerabilityResponseEffort": "MODERATE"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Firewall administrators can see traffic that they should not be able to see, which impacts confidentiality but there is no impact to integrity or availability of that traffic."
            }
          ]
        },
        {
          "cvssV4_0": {
            "Automatable": "NO",
            "Recovery": "AUTOMATIC",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "LOW",
            "attackRequirements": "PRESENT",
            "attackVector": "LOCAL",
            "baseScore": 0,
            "baseSeverity": "NONE",
            "privilegesRequired": "HIGH",
            "providerUrgency": "CLEAR",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "valueDensity": "DIFFUSE",
            "vectorString": "CVSS:4.0/AV:L/AC:L/AT:P/PR:H/UI:N/VC:N/VI:N/VA:N/SC:N/SI:N/SA:N/AU:N/R:A/V:D/U:Clear",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "NONE",
            "vulnIntegrityImpact": "NONE",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "There is no risk if the firewall is licensed for decryption port mirroring because firewall administrators are already authorized to obtain decrypted packet captures from Palo Alto Networks firewalls."
            }
          ]
        }
      ]

My question is: when multiple cvssV4_0 entries are provided by the same data provider (e.g. MITRE), is there a documented or recommended way to determine which one should be used? For instance, is the first entry always the most recent or most accurate? Or should we rely on another field to make that decision?

And more generally: does the same logic apply to other score types (cvssV3_1, cvssV3_0, etc.) if multiple versions exist in the array?

Any clarification or official guidance on this would be really appreciated — it would help ensure we aggregate and display the most relevant score to our users.

Thanks a lot for your work and support!

ncrocfer avatar Apr 23 '25 19:04 ncrocfer

These are issues with the records themselves. You will need to contact the owning CNA in order to get more information, or for them to correct it - if that is necessary. CVE-2025-0123 is specifically owned by the palo_alto CNA, so you would need to reach out to them about that one.

There is no guarantee that the order of any data is consistent or correlated to the release date. Your best bet might be to look at the github history for the CVE file and see if the duplicate data was added at a different time. For example, in CVE-2025-0123, both cvssV4_0 fields seem to have been added at the same time, at its initial publication. However, due to the nature of JSON, every leaf element that does not have a UUID attached to it has the chance that it was removed and replaced with something else instead of a "minor" change being made to one. For the image example, all of the following scenarios are possibly valid:

Image

  • A updated to B, and C added
  • A updated to C, and B added
  • A removed, and B and C added

M-nj avatar Apr 23 '25 21:04 M-nj