Threat/Temporal metrics in CVSS vectors make severity time-dependent and inconsistent with how the Advisory Database displays and edits CVSS #10211

Summary

Many GitHub-reviewed advisories include CVSS v4.0 Threat Metrics (e.g. E:U) or CVSS v3.x Temporal Metrics (e.g. E:U/RL:O/RC:C) in their vector strings, and the displayed score and severity are calculated with them. However, the Advisory Database UI, the "Suggest improvements" form, and the data model all assume that only Base Metrics are stored. This mismatch causes inaccurate or unstable severities and makes community contributions silently change severity.

I'd like to propose that the GitHub Advisory Database store only Base Metrics. If Threat/Temporal Metrics are kept, I propose that they be handled explicitly, as described below.

Background

This was first discussed in #5663 (GHSA-g88v-2j67-9rmx). @shelbyc explained that Threat Metrics are included because the CVSS v4.0 specification recommends them, and because GitHub acts as a CVE consumer as well as a CNA. I understand that reasoning. I still think the current implementation causes the practical problems below.

What the CVSS specification says

• Threat and Environmental Metrics are the consumer's responsibility. The CVSS v4.0 User Guide (section "CVSS Nomenclature", Additional Notes) states: "The application of Environmental and Threat metrics is the responsibility of the CVSS consumer." It also notes that vendors and organizations such as NVD typically publish only Base scores. The Specification Document (Introduction > Assessment) likewise describes Threat and Environmental Metrics as being assessed by consumer organizations, which can best judge the impact in their own environments.
• Threat Metrics change over time. The Specification Document (Introduction > Metrics) describes the Threat group as capturing characteristics that change over time. The Exploit Maturity values are intended to be populated from threat intelligence. The same applies to the Temporal metric group in CVSS v3.x, which v4.0 renamed to Threat.
• Scores that include Threat Metrics must be labeled. The Specification Document (Introduction > Nomenclature) says this nomenclature should be used wherever a numerical CVSS value is displayed or communicated. A score that uses any Threat metric is CVSS-BT, not CVSS-B. Likewise, a score that uses Environmental Metrics is CVSS-BE or CVSS-BTE.
• About "highly recommended". The specification indeed says that assessing Threat and Environmental Metrics is highly recommended for more meaningful results. In context, however, this recommendation is addressed to consumers who score vulnerabilities for their own environment, using up-to-date threat intelligence. It is not addressed to the provider of a shared database whose severity is consumed by many downstream users.

Scale of the issue

Counted over advisories/github-reviewed in this repository (as of 2026-10-07):

• CVSS v4.0: 1,503 vectors contain an E value other than X (E:P 861, E:U 613, E:A 29). In 1,096 advisories, the severity calculated from the full vector (CVSS-BT) differs from the Base-only severity (CVSS-B). In all 1,096 cases it is lower, and database_specific.severity follows the lowered value.
• CVSS v3.x: 120 vectors contain Temporal Metrics (E/RL/RC). In several v3-only advisories, the displayed score and severity are the Temporal Score, not the Base Score. For example:
  • GHSA-659f-rgp5-w4wf: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N/E:U/RL:O has a Base Score of 10.0 (Critical) but is displayed as 8.7 (High).
  • GHSA-92xj-mqp7-vmcj: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H/E:P/RL:O/RC:C has a Base Score of 9.8 (Critical) but is displayed as 8.8 (High).
• Environmental Metrics: One CVSS v4.0 vector (GHSA-hjj4-hfjm-fmrj) also contains Environmental and Supplemental Metrics. Its CVSS-B score is 6.3 (Medium), but the advisory's severity is Low. Environmental Metrics are, by definition, specific to each consumer's environment, so they should not be stored in a shared database at all.

Problems

1. Threat/Temporal Metrics are a point-in-time assessment, but they are not maintained

Exploit Maturity changes over time as PoCs are published, exploit tools appear, and in-the-wild exploitation is reported; the specification itself describes Threat Metrics as time-dependent (see above). Including them in a stored vector therefore requires continuously monitoring and updating every affected advisory. Otherwise the values become stale.

A stale E:U lowers the severity. For example, CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N scores 5.1 (Medium), but adding /E:U brings it to 1.2 (Low). Downstream tools such as Dependabot and other scanners consume this severity and often filter on it, so an outdated E:U can cause real vulnerabilities to be deprioritized.

2. The displayed metrics and the calculated score do not match

The advisory page shows only the base metrics, but the overall score and severity include Threat/Temporal Metrics. Users cannot tell from the page why the score differs from the Base Score. The score is also not labeled CVSS-BT, as the specification's nomenclature requires, and the CVSS-B score is not shown alongside it.

3. The "Suggest improvements" form cannot handle non-base metrics (#5357)

The CVSS 4.0 calculator in the form rejects vectors containing Threat Metrics. Contributors who only want to fix something unrelated, such as version ranges, are forced to delete E:x, which silently changes the severity. In #9632 (GHSA-8wpr-639p-ccrj), removing E:U only to get the form to accept the change moved the severity from MODERATE to CRITICAL. Other PRs have had to drop the Threat metric for the same reason, e.g. #6743 and #8942.

4. Inconsistent application

Threat/Temporal Metrics appear on some advisories but not others, and there is no public documentation of when they are added or how they are kept up to date (see also #5058 and #6841). As a result, severities are not comparable across advisories.

Proposal

Option A (preferred): store Base Metrics only

• Accept and store only Base Metrics for both CVSS v3.x and v4.0, and validate submitted vectors accordingly.
• Remove Threat/Temporal and Environmental Metrics from existing vectors and recalculate severity.
• Leave threat context to dedicated signals that are already available or better suited, such as EPSS, which the Advisory Database already shows, and CISA KEV.

Option B: if Threat/Temporal Metrics are kept

• Display both the Base Score and the score including Threat/Temporal Metrics, with severities for both, labeled according to the CVSS v4.0 nomenclature (CVSS-B, CVSS-BT). Environmental Metrics should not be stored; if they ever are, the resulting score must be labeled CVSS-BE or CVSS-BTE and never used as the advisory's severity.
• Show the Threat/Temporal Metrics on the advisory page, not only the Base Metrics.
• Support these metrics in the "Suggest improvements" form (CVSS 4.0 calculator on advisory improvement screen does not support non-base metrics #5357).
• Document when these metrics are assessed and how they are kept up to date.

Related

• [GHSA-g88v-2j67-9rmx] Fess has Insecure Temporary File Permissions #5663 (original discussion)
• CVSS 4.0 calculator on advisory improvement screen does not support non-base metrics #5357 (form does not support non-base metrics)
• Stop creation of CVSS v4 by yourself #5058, CVE-2026-22028 Significant scoring difference between GHSA<>NVD #6841 (transparency and consistency of GitHub-assigned CVSS)
• [GHSA-8wpr-639p-ccrj] Nest has a Fastify URL Encoding Middleware Bypass (TOCTOU) #9632, [GHSA-73rr-hh4g-fpgx] jsdiff has a Denial of Service vulnerability in parsePatch and applyPatch #6743, [GHSA-569q-mpph-wgww] Better Auth affected by external request basePath modification DoS #8942 (examples where E was removed to submit improvements)