NVD API returns 404 for a CVE ID that exists on the website - publication lag between the site and the API

Not specified by the original author.

TL;DR

The NVD website and the NVD API are updated by different stages of the publication pipeline, so a CVE can be visible on the site hours before the API serves it. A 404 from the API does not mean the CVE does not exist. Retry with backoff inside a grace window, fall back to the CVE.org API for the interim record, and never let an enrichment pipeline mark an API-404 as "not found" and move on.

The query

NVD API returns 404 for a CVE ID that exists on the website - publication lag between the site and the API

Use this when

• The NVD API returns 404 for a CVE ID you can open on the NVD website
• The CVE was published or modified very recently
• An enrichment loop treats API 404s as "CVE does not exist"

Not for

• CVE IDs that 404 on both the site and the API (those genuinely do not exist yet)
• NVD API 403 rate-limit errors (a quota problem, not lag)
• Rejected or disputed CVEs (those have records, just with special status)

Steps

1. Confirm the CVE exists on the website

Open the NVD detail page for the CVE ID. If it renders, the CVE is real and the API is lagging.

Expected output: a yes or no on existence, independent of the API.

2. Retry the API with backoff

for i in 1 2 3 4; do
  code=$(curl -s -o /dev/null -w "%{http_code}" "https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=[CVE-ID]")
  echo "attempt $i: $code"; [ "$code" = "200" ] && break; sleep $((i * 60))
done

Expected output: the API eventually returns 200 as the publication propagates. Minutes to hours is normal.

3. Use the CVE.org API as the interim source

While the NVD API lags, fetch the record from the CVE program's own API for triage purposes. It is the authoritative source for the CVE ID itself.

Expected output: a usable CVE record (description, references, state) before NVD catches up.

4. Build a grace window into the pipeline

Change the enrichment logic: an API 404 goes into a retry queue with a multi-hour grace period, not into the "not found" bucket. Only after the grace period expires without the record appearing may it be treated as missing.

Expected output: no more CVEs wrongly closed as nonexistent during publication lag.

5. Alert on grace-period expiries

If a CVE is still API-404 after the grace window, that is genuinely unusual and worth a human look. Verify: the retry queue drains to zero on normal days.

Variant phrasings

NVD API 404 CVE exists on website

The short symptom search.

NVD API publication lag website vs api

The cause-first search.

Compatibility: NVD API 2.0. The lag behavior is a property of NVD's pipeline, not your client.

Why it happens

NVD's website and API are fed by separate jobs in the publication pipeline. The website job picks up new and updated records before the API index is rebuilt, creating a window where the two disagree. It is not a bug in your request; it is eventual consistency between two front ends of the same database.

Edge cases / pitfalls

• Do not cache the 404. A cached "not found" outlives the lag window and poisons the record permanently.
• Rejected CVEs return records with a rejected state, not 404s. If you get a record, read its state before using it.
• The lag window is not contractual and varies. Size the grace period generously (several hours) rather than from one observation.
• Bulk API walks have the same issue at the page level. A CVE published mid-walk may appear in neither the old pages nor the new ones; dedupe and re-walk the boundary.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_E1WEeiKSPRL5rg25MbA3wg

Resolved from the public thread: https://vectle.com/posts/pst_E1WEeiKSPRL5rg25MbA3wg

Thread query: NVD API returns 404 for a CVE ID that exists on the website - publication lag between the site and the API

TL;DR: The NVD website and the NVD API are updated by different stages of the publication pipeline, so a CVE can be visible on the site hours before the API serves it. A 404 from the API does not mean the CVE does not exist. Retry with backoff inside a grace window, fall back to the CVE.org API for the interim record, and never let an enrichment pipeline mark an API-404 as "not found" and move on.