Verify before acting

Aggregation is worth having right up to the moment an agent changes a production dependency. Then the question stops being "what do you know" and becomes "is it still true".

GET /api/v1/cve/{id}/verify

This re-reads the record from the CVE Program list, uncached, and compares it against what this service holds. Run it immediately before acting, not as part of a browse.

Why it exists

Someone evaluating this API for autonomous dependency changes said they would use it as the aggregation and control plane, then add a final upstream check of their own before acting. Every consumer doing that writes the same check, so it belongs here.

Response

json

{
  "success": true,
  "data": {
    "cveId": "CVE-2026-26157",
    "storedFrom": "cve_history_2026_02",
    "verdict": "differs",
    "safeToActOn": true,
    "blockingFields": [],
    "differences": [
      { "field": "dateUpdated", "ours": "2026-02-15T15:03:49Z", "upstream": "2026-07-15T01:15:16Z" }
    ],
    "notComparable": [],
    "upstreamState": "PUBLISHED",
    "checkedAt": "2026-09-11T04:12:00Z"
  }
}

Verdicts

Verdict	Meaning
`matches`	Every field we hold and can compare agrees with upstream.
`differs`	Something moved. `differences` says what.
`not_stored`	We hold no record of our own. Most identifiers are proxied on demand rather than stored, so this is common and is not a failure. The authoritative state is still reported.
`unverified`	Upstream could not be read. This is never reported as agreement.

The field that matters

safeToActOn is false when the state or the affected set has moved, and false when upstream could not be read. It is also false when upstream has rejected the CVE, including when we held no state of our own to notice the change.

A rejected CVE is the case worth guarding. Every other field still looks reasonable, and an agent acting on it does work that was never needed.

Fields we do not hold

notComparable lists fields absent from our stored record. A field we never held cannot disagree with upstream, and counting its absence as a difference made every record we hold look changed.

Does a release mention the CVE

GET /api/v1/verify-fix?url=https://github.com/curl/curl/releases/tag/curl-8_4_0&cves=CVE-2023-38545,CVE-2023-38546

A narrower question than the record check above: whether a GitHub release's notes or a commit's message name the CVE ids given. It is a text search, not a verification. A release note that names a CVE is evidence somebody said it was addressed there; one that does not name it is not evidence that it was missed. Treat the answer as a pointer to read the page, never as a fix claim.

Parameter	Required	Description
`url`	Yes	A GitHub release (`/owner/repo/releases/tag/TAG`) or commit (`/owner/repo/commit/SHA`) URL. Only github.com is accepted, so the route cannot be used to reach arbitrary hosts.
`cves`	Yes	Comma-separated CVE ids. Anything that is not a CVE id is dropped; if nothing remains the answer is `400`.

json

{
  "success": true,
  "data": {
    "found": false,
    "mentions": [],
    "releaseUrl": "https://github.com/curl/curl/releases/tag/curl-8_4_0"
  }
}

mentions lists the ids that appear in the text and found is true when there is at least one. A tag that does not exist is retried against the common spellings (v1.2.3, 1.2.3) and releaseUrl names the one that answered. GitHub holding no release or commit at that URL answers 422; GitHub not answering is 502. Neither is found: false, because a page that could not be read has not been searched.

Verify before acting ​

Why it exists ​

Response ​

Verdicts ​

The field that matters ​

Fields we do not hold ​

Does a release mention the CVE ​