Skip to content
CVE Tracker

Changelog

What changed on trackcve.app and in its API, newest first. The data itself changes every few minutes and is not listed here; this is about what the site and the API can do.

API releases carry the version of the /v1 contract; how it is versioned is at the end of this page.

2026-11-03

API 1.4.0

  • GET /v1/vendors/{vendor}?product=: one vendor's or product's CVEs by severity and year, with its top products and weaknesses, the newest and the known exploited.
  • GET /v1/cwes/{cwe}: the CVEs of one weakness by severity and year, with the vendors it comes up for most, the newest and the known exploited.
  • GET /v1/weekly?week=2026-W45: one ISO week of CVEs, with counts by severity, the most severe, KEV additions, and the top vendors and weaknesses.

API 1.3.0

  • GET /v1/epss/movers?window=1d|7d|30d: the 50 CVEs whose EPSS rose the most over the last day, week or month, with the earlier score as epssBefore.

API 1.2.0

  • Filters cwe (a weakness, CWE-79 or 79) and assigner (the CNA's short name) on /v1/cves, /v1/timeline and /v1/export, with suggestions from GET /v1/cwes and GET /v1/assigners.
  • sort=kevAdded orders the list by the day CISA added each CVE to KEV, and every row has that day as kevAdded.
  • GET /v1/stats?range=7d|30d|90d|12m: severity, top weaknesses, vendors and CNAs of the CVEs published in a window, and how many CISA added to KEV.

API 1.1.0

  • GET /v1/openapi.json: an OpenAPI 3.1 description of the whole API, generated from the schemas the answers are checked against. Generate a client in any language from it.
  • strict=true on /v1/cves, /v1/timeline and /v1/export: an unknown parameter or a value the filter would otherwise ignore is a 400 that names the problem, instead of a wider result.
  • /v1/health reports the deployed commit as version instead of dev.

Site

  • Quick search: ⌘K (Ctrl+K) or / on any page, or the search button in the header, opens a CVE by its id, a vendor, a weakness or any page, or searches the whole list.
  • Vendor and product pages, such as Microsoft: CVEs per year, how many are critical and known exploited, the products and weaknesses that come up most, and the newest CVEs, with a feed. The affected products on a CVE's page link to them, and the sitemap lists the 2,000 vendors with the most CVEs.
  • Weakness pages, such as CWE-79: how many CVEs of the kind there are per year, how many are exploited, the vendors it comes up for most and the newest, with a feed and a link to MITRE's description. A CVE's weaknesses link to them.
  • Weekly digest: any ISO week (/week/2026-W45) at a glance: how many CVEs, how severe, the worst of them, what CISA added to KEV, and the vendors and weaknesses named most, with links to the weeks before and after.
  • Rising exploitation: the CVEs whose EPSS rose the most since yesterday, last week or last month, often a sign of attacks before CISA adds them to KEV.
  • Recently added to KEV: what CISA added to its catalog, by day, with an Atom feed of new additions (/feed.xml?sort=kevAdded).
  • Statistics: severity, the most common weaknesses, vendors and CNAs of the last 7 days to 12 months; every number opens the CVEs behind it.
  • Watchlist: watch any filter (a vendor, a package ecosystem, a weakness) from the list and see what each found in the last week, with all their feeds as one OPML file. Kept in your browser; no account.
  • Weakness (CWE) and CNA filters in the list; a CVE's page links to the other CVEs with the same weakness or from the same CNA.
  • A badge for a README or a ticket, /badge/CVE-….svg, with the CVE's severity, score and KEV status; its Markdown is on every CVE page.
  • How it's built: the tech stack and how the site keeps its data current, fast and secure.
  • KEV and Stats in the header.
  • API documentation: every endpoint, filter and field, with rate limits, error codes, recipes for shell scripts and an outline of the page (folded on a phone). Code examples have a copy button.
  • This changelog.
  • Data sources says whether every source is up to date, and names the one that is delayed when one is.

2026-11-02

  • Illustrations for an empty result, a lost connection and a page that does not exist.
  • A fuller footer on every page: where to go next, the author, and the attributions the sources ask for.
  • /.well-known/api-catalog (RFC 9727) and /.well-known/ai-catalog.json point programs and AI agents to the API, the feed and llms.txt.
  • When cisa.gov refuses the download, the KEV catalog is read from CISA's own copy on GitHub, so known exploited flags no longer fall behind.

2026-11-01

  • WebMCP tools: an AI agent in the browser can search and filter CVEs, read their details, the timeline and the summary, and get export links, through the page itself.
  • The first full read of the CVE List resumes where it stopped after an interruption instead of starting over.

2026-10-27

  • Fair limits for the pages themselves: the site's server rendering is counted per visitor, so one busy visitor cannot use up the API for everyone.
  • Self-hosting: DEPLOY.md and two scripts set the whole site up on a small server behind a Cloudflare Tunnel, and update it.

2026-10-26: first release

API 1.0.0

  • /v1/cves with filters by text, severity, CISA KEV, vendor, product, package ecosystem and publication date, in any order; /v1/cves/{id} with every CVSS score, affected versions, references, KEV, EPSS, SSVC and packages; /v1/cves/{id}/epss with the last month of EPSS.
  • /v1/export for a whole filter as CSV or JSON, /v1/timeline, /v1/summary, and /v1/vendors, /v1/products and /v1/ecosystems for the filters.
  • 120 requests a minute per address, with RateLimit-* headers; answers cached by the CDN in front.

Site

  • The timeline of every published CVE by severity, the filterable list, and a page for each CVE.
  • An Atom feed for any filter, each CVE as Markdown (/cve/{id}.md), llms.txt, sitemaps and security.txt.
  • About and Data sources pages.
  • Light and dark themes, loading states that keep the current results in view, and WCAG 2.2 AA accessibility, checked by an automated audit on every change.

Versioning policy

The /v1 contract is versioned semantically; its version is info.version of /v1/openapi.json.

  • Within /v1 only additions are made: a new endpoint, parameter, field or enum value. Nothing is removed, renamed or changes meaning or type. Ignore fields you do not know, and treat an enum value you do not know (a new severity, a new source) as "other".
  • Lenient defaults stay lenient. A request that works today keeps working; stricter checks are opt-in (strict=true).
  • A breaking change gets a new path (/v2), announced here, with /v1 kept running alongside it for at least six months.
  • Error messages are for people and may be reworded at any time; codes are part of the contract.