Skip to content

Multiple broken URLs in CNAsList.json — May 2026 audit (17 CNAs, 23 URLs) #3937

@kurtseifried

Description

@kurtseifried

Multiple broken URLs in CNAsList.json — May 2026 audit (17 CNAs, 23 URLs)

An audit of the 1,122 URLs in src/assets/data/CNAsList.json (across the disclosurePolicy[], securityAdvisories.advisories[], securityAdvisories.alerts[], contact[].contact[], and contact[].form[] fields) found 23 URLs across 17 CNAs that are confirmed broken as of 2026-05-08.

Methodology (so this is reproducible)

For each URL: HTTP GET via httpx (follow redirects, capture status + body sample); ambiguous results (403, network errors) re-tested via headless Chromium / Playwright with browser fingerprint + the user's installed Chrome channel; remaining ambiguities verified manually in a normal browser. Network-layer reachability (DNS resolution + TLS handshake on port 443) checked separately on the host without HTTP. The 23 below are the URLs that failed all of those checks, including a manual visit in a real browser.

The full audit (1,122 URLs, 502 CNAs, including the false-positive shake-out of bot-blocked-but-working URLs) is in CloudSecurityAlliance/SecID/working-data/cve-org-url-audit/ — scripts, raw CSVs, and screenshots.

Prior issues for the same dataset

The CVE Project has fixed similar broken-URL reports in the past, but the fixes degrade over time as vendor sites are reorganized:

Closing these as one-off fixes addresses the symptom; the URLs in CNAsList.json have no pre-merge validation and CNAs occasionally reorganize their security pages without notifying anyone. Three of the 17 CNAs below are repeat offenders.

The 17 CNAs and 23 broken URLs

Format: [failure_kind] field_path: URL

Failure kinds:

  • hard_404 — server returned HTTP 404
  • confirmed_dead_connect — DNS resolves but TCP/HTTPS connection fails (host genuinely unreachable from outside its network)
  • confirmed_dead_ssl — TLS handshake fails (client-cert required, locked cipher, or misconfigured WAF)
  • bot_blocked — server returns 403 to httpx, headless Chromium, and channel=chrome-launched Chrome with realistic fingerprint, but works in a manual-Chrome session

Black Lantern Security (BLSOPS, CNA-2023-0027)

CTOne Inc. (CTOne, CNA-2025-0019)

Dragos, Inc. (Dragos, CNA-2022-0030)

Hitachi Energy (Hitachi_Energy, CNA-2021-0028)

Indian Computer Emergency Response Team (CERT-In) (CERT-In, CNA-2021-0050)

(Note: CERT-In's host appears to be geo-restricted — it may resolve from inside India but times out from outside.)

KrCERT/CC (krcert, CNA-2016-0021) — prior issue: #898 (closed)

National Cyber Security Centre Finland (NCSC-FI) (NCSC-FI, CNA-2023-0033) — prior issue: #283 (closed)

OMRON Corporation (OMRON, CNA-2024-0070)

(OMRON's WAF blocks all automated traffic. Real-browser verification: the URLs return error pages, not the intended forms — this was confirmed in a manual visit. Either the WAF is misconfigured or the form pages have been retired.)

Omnissa, LLC (Omnissa, CNA-2024-0078)

Palo Alto Networks, Inc. (palo_alto, CNA-2018-0005)

(Hostname has been retired — Palo Alto moved their security advisories to a different domain.)

Patchstack (Patchstack, CNA-2021-0025)

STAR Labs SG Pte. Ltd. (STAR_Labs, CNA-2023-0010)

Silicon Labs (Silabs, CNA-2021-0056)

Switzerland National Cyber Security Centre (NCSC) (NCSC.ch, CNA-2021-0040)

Temporal Technologies Inc. (Temporal, CNA-2023-0030)

Trellix (Trellix, CNA-2016-0022)

(Hostnames are retired post-FireEye/McAfee → Trellix rebrand.)

openGauss Community (openGauss, CNA-2022-0019) — prior issue: #1495 (closed)

Bonus: malformed URL (separate from the 23 above)

HDFG (HDF Group, CNA-2022-0058) has a leading space in disclosurePolicy[0].url:

"url": " https://github.com/HDFGroup/hdf5/security/policy"

The URL itself is fine — the path resolves correctly once the leading space is stripped — but httpx, strict URL parsers, and any code that treats the field as-is will fail with unsupported_protocol. Worth a one-character fix.

Suggested next step

Reach out to each affected CNA's security contact to provide an updated URL, then update CNAsList.json. If a CNA can't provide a working URL, removing the broken entry is preferable to leaving a 404 — the CVE Record reader will at least see no URL rather than a dead one.

For the longer-term gap, a periodic CI check that issues a HEAD/GET against every URL in CNAsList.json on a cadence (weekly, monthly) and opens an issue when one fails would prevent these from accumulating. Happy to share the audit script if useful.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    Status

    Needs Triage

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions