redhat-SADP container contradicts the Red Hat CNA container's affected status on identical product entries

[jgamblin]

redhat-SADP container contradicts the Red Hat CNA container's affected status on identical product entries

Summary

In CVE records where Red Hat is both the assigning CNA (CVE Numbering Authority) and the SADP (Supplier ADP) enrichment source, the redhat-SADP container assigns a different affected/unaffected status than Red Hat's own CNA container for the identical product entry (same product string, same CPE). The record therefore carries two conflicting answers from the same vendor for the same product, and there is no documented precedence rule telling a consumer which one wins.

This is not a product-line-versus-specific-version distinction. Both containers list the product as its own affected-array entry with an empty versions[]; only defaultStatus differs.

Scope: this affects only the same-org records (Red Hat as both CNA and supplier). For the roughly 90% of records where Red Hat is not the CNA, the SADP container is additive and this issue does not apply.

Worked example: CVE-2026-9795 (Keycloak)

Both containers describe the same product Red Hat build of Keycloak 26.4.13 (the patched build) with the same CPE, but with opposite status.

CNA container (redhat) affected entry:

{
  "vendor": "Red Hat",
  "product": "Red Hat build of Keycloak 26.4.13",
  "defaultStatus": "unaffected",
  "cpes": ["cpe:/a:redhat:build_keycloak:26.4::el9"]
}

redhat-SADP container affected entry:

{
  "vendor": "Red Hat",
  "product": "Red Hat build of Keycloak 26.4.13",
  "defaultStatus": "affected",
  "cpes": ["cpe:/a:redhat:build_keycloak:26.4::el9"]
}

Record: https://cveawg.mitre.org/api/cve/CVE-2026-9795

Extent

Across the 110 same-org records in the snapshot below, 21 records contain at least one product entry whose status the two Red Hat containers report differently. There are 39 conflicting product entries in total:

• 38 entries: the CNA marks the product unaffected, the SADP container marks it affected. These are Keycloak, JBoss EAP, and Apache Camel builds. They include confirmed fixed builds (for example Keycloak 26.4.13, 26.6.4) that the CNA correctly records as unaffected.
• 1 entry: the reverse. In CVE-2026-3238, Red Hat OpenShift Container Platform 4 is affected in the CNA container and unaffected in the SADP container.

One further record, CVE-2026-6266, has a CVSS disagreement rather than a status one: CVSS v3.1 base score 8.3 (A:L) in the CNA container versus 8.1 (A:N) in the SADP container.

Affected records (Keycloak unless noted): CVE-2026-1486, CVE-2026-1529, CVE-2026-2092, CVE-2026-2603, CVE-2026-3009, CVE-2026-3047, CVE-2026-3872, CVE-2026-4282, CVE-2026-4634, CVE-2026-4636, CVE-2026-7307, CVE-2026-7504, CVE-2026-7507, CVE-2026-9086, CVE-2026-9099, CVE-2026-9795, CVE-2026-9800, CVE-2026-11800; CVE-2025-12543 (JBoss EAP and Apache Camel); CVE-2026-6857 (Apache Camel); CVE-2026-3238 (OpenShift, reverse direction).

Why it matters

• Consumers that read only the SADP container see products the CNA marks unaffected, including patched builds such as Keycloak 26.4.13, reported as affected. A scanner acting on that flags an already-remediated system as vulnerable, which is a false positive. False positives on patched systems are among the most expensive failure modes in vulnerability management: they waste remediation effort and erode trust in the feed.
• Consumers that merge all containers in the record get two same-vendor answers for the same product string and CPE, with no rule for which container is authoritative. The status is ambiguous rather than usable.

The underlying gap is that the pilot does not define precedence between a CNA container and a same-org supplier ADP container when they disagree on the same key.

Suggested fixes

1. Add a same-org consistency check to the generation pipeline that fails or flags any record where the supplier ADP affected/unaffected status or CVSS disagrees with that same organization's CNA container for the same product entry. This check would have caught all 21 status records and the CVSS record.
2. Document a precedence rule for same-org records so consumers know which container is authoritative when the CNA and supplier ADP disagree.

Snapshot and reproducibility

• CVE records retrieved from GET https://cveawg.mitre.org/api/cve/{id} on 2026-07-01 (UTC).
• SADP corpus (the set of redhat-SADP CVE IDs) taken from RogoLabs/SADP-Tracker at commit c000694. Data source for that corpus is CVEProject/sadp-pilot.
• CNA identity matched on providerMetadata.orgId, not name. Red Hat CNA org is 53f830b8-0a3f-465b-8143-3b8a9948e749; the redhat-SADP supplier org is 0b0ca135-0b70-47e7-9f44-1890c2a1c46c (a distinct org identity).
• CVE records are living documents, so absolute counts may drift on later pulls. The pattern is structural. CVE-2026-9795 was last updated 2026-06-30 at the time of retrieval.
• Related: see companion issue redhat-SADP container restates the Red Hat CNA container's descriptions and metrics in same-org records #16 on same-org restatement of descriptions and metrics (redundancy). This contradiction and that redundancy are two symptoms of the CNA and supplier ADP containers being generated independently for the same organization.

[pedrohc]

@jgamblin Thank you for reporting this. We have pushed a fix to our tools today that resolved the affected status problems. Very minor discrepancies between the cna and adp container's affected sections still exists but only a for few edge cases.