DEV Community

Cover image for 8 Free CVE & Vulnerability APIs With No Key (2026)
Alex Spinov
Alex Spinov

Posted on • Originally published at blog.spinov.online

8 Free CVE & Vulnerability APIs With No Key (2026)

#security #api #python #devops

Everyone bookmarks the NVD API and stops there. Looking up a CVE by ID is the easy ten percent of the job. The harder question is which of the hundreds of open CVEs in your stack to patch tonight, and that answer is not in the CVE description. It lives in EPSS, the odds the thing actually gets exploited, and in CISA KEV, the list of what already is. Both are free, both are keyless, and a CVSS 9.8 that nobody will ever weaponize is a lower priority than a CVSS 6 that ransomware crews are using this week.

A free CVE API returns vulnerability data for a CVE, a package, or an IP without a paid vendor or an API key. The eight below need no key and no signup. I re-verified each with a live curl on July 3, 2026 (HTTP 200), and every response you see is the real output, trimmed for length, not paraphrased. If you scrape or monitor targets like I do, the output is a list of domains, IPs, and dependencies. These are the lookups that add a security column to that list.

Let me be straight about what this is not. I am not claiming I ran a vulnerability scanner across my 2,190 production scraper runs. That would be a lie. These are the free lookups I reach for when a target list needs a "is this vulnerable, is it being exploited" answer, and none of them need a billing setup. This is triage and recon data, not a pentest guide. Scan only IPs you own or the explicit public test host below.

Here is the full set at a glance, grouped by the job each one does, then a section each.

# API Job to be done Example call No key?
1 NVD (NIST) Look up a CVE (US canonical record) GET /rest/json/cves/2.0?cveId= Yes (~5 req/30s)
2 CIRCL Vulnerability-Lookup Look up a CVE (CVE 5.1 record, fast) GET /api/vulnerability/CVE-… Yes
3 Red Hat Security Data Distro severity + fix state (RHEL) GET /hydra/rest/securitydata/cve/…json Yes
4 Ubuntu Security Distro status (Ubuntu packages) GET /security/cves/CVE-….json Yes
5 OSV.dev (Google) Scan a package for vulns POST /v1/query (ecosystem+version) Yes
6 FIRST EPSS Odds a CVE gets exploited GET /data/v1/epss?cve= Yes
7 CISA KEV What is already being exploited JSON feed (download + filter) Yes
8 Shodan InternetDB CVEs and ports for an IP GET internetdb.shodan.io/<ip> Yes

I used to bookmark NVD and call it a day, which is exactly the mistake I am warning you about. Group C is where the real work happens.

Group A: look up a CVE by ID (one CVE, four lenses)

1. NVD: the NIST canonical record (global)

NVD is the reference answer for "what is this CVE." It is the US National Vulnerability Database, run by NIST, and it is the record everything else points back to. One GET, no key.

# runnable, read-only
curl -A "my-tool/1.0 (you@example.com)" \
  "https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2021-44228"
Enter fullscreen mode Exit fullscreen mode 
{"resultsPerPage":1,"totalResults":1,"format":"NVD_CVE","version":"2.0",
 "vulnerabilities":[{"cve":{"id":"CVE-2021-44228","sourceIdentifier":"security@apache.org",
   "published":"2021-12-10T10:15:09.143","vulnStatus":"Analyzed",
   "descriptions":[{"lang":"en","value":"Apache Log4j2 2.0-beta9 through 2.15.0 ... JNDI features ... An attacker who can control log messages ... can execute arbitrary code loaded from LDAP servers ..."}],
   "metrics":{"cvssMetricV31":[{"cvssData":{"baseScore":10.0}}]}}}]}
Enter fullscreen mode Exit fullscreen mode

That is Log4Shell, scored 10.0 by NVD. The rate limit is the catch, and it is documented: about 5 requests per rolling 30 seconds without a key, which a free API key lifts to 50. I fired six requests back to back and all six returned 200, so enforcement felt soft that morning, but I would not build a bulk job on that luck. Grab the free key if you need volume. Source: nvd.nist.gov/developers/start-here, and verify the current number before you rely on it.

When to use it: the authoritative description and CVSS metrics for a single CVE. Slowest of the four here, richest metadata.

2. CIRCL Vulnerability-Lookup: the fast CVE 5.1 record (global)

CIRCL is the Luxembourg CERT, and their Vulnerability-Lookup platform serves the raw CVE 5.1 JSON record fast. No key.

# runnable, read-only
curl "https://vulnerability.circl.lu/api/vulnerability/CVE-2021-44228"
Enter fullscreen mode Exit fullscreen mode 
{"dataType":"CVE_RECORD","dataVersion":"5.1",
 "cveMetadata":{"state":"PUBLISHED","cveId":"CVE-2021-44228",
   "assignerShortName":"apache","datePublished":"2021-12-10T00:00:00.000Z"},
 "containers":{ ... }}
Enter fullscreen mode Exit fullscreen mode

That came back as 18,994 bytes. One quirk worth knowing: the old host https://cve.circl.lu/api/cve/CVE-2021-44228 still answered 200 with the identical 18,994-byte body when I checked on July 3, so the legacy endpoint is alive, but the canonical one now is vulnerability.circl.lu. Point new code at the new host.

When to use it: a quick raw record without NVD's rate ceiling, or as a second source when NVD is throttling you.

3. Red Hat Security Data API: distro severity and fix state (RHEL)

Here is where a single number stops being a single number. Red Hat publishes its own security data, keyless, and it carries something NVD does not: the fix state for Red Hat packages.

# runnable, read-only
curl "https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2021-44228.json"
Enter fullscreen mode Exit fullscreen mode 
{"threat_severity":"Critical","public_date":"2021-12-10T02:01:00Z",
 "bugzilla":{"description":"log4j-core: Remote code execution in Log4j 2.x ...","id":"2030932"},
 "cvss3":{"cvss3_base_score":"9.8",
   "cvss3_scoring_vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"},
 "cwe":"CWE-20"}
Enter fullscreen mode Exit fullscreen mode

Note Red Hat scored Log4Shell 9.8, while NVD lists it 10.0. Same CVE, different vendor, different number. The full response also carries an affected_release array (43 entries when I pulled it) and a package_state block, so you can answer "is my RHEL package patched yet" instead of just "how bad is it in the abstract."

When to use it: you run RHEL, CentOS Stream, or Fedora and need the vendor's severity and patch status, not the generic score.

4. Ubuntu Security CVE API: the same CVE, a different score (Ubuntu)

Canonical runs the same idea for Ubuntu, keyless, at a clean JSON endpoint.

# runnable, read-only
curl "https://ubuntu.com/security/cves/CVE-2021-44228.json"
Enter fullscreen mode Exit fullscreen mode 
{"cvss3":10.0,"priority":"high",
 "description":"Apache Log4j2 2.0-beta9 through 2.15.0 ... JNDI features ... execute arbitrary code ...",
 "codename":null,
 "impact":{"baseMetricV3":{ ... }},
 "packages":[ ... ],"patches":[ ... ]}
Enter fullscreen mode Exit fullscreen mode

Line the last two up. Red Hat scored CVE-2021-44228 at 9.8. Ubuntu scored the exact same CVE at 10.0. Severity is context-dependent, so query the distro you actually run rather than trusting one number as gospel. The packages and patches arrays tell you which Ubuntu releases are fixed.

When to use it: you run Ubuntu or Debian and want Canonical's priority and per-release patch state.

Group B: scan a package for vulnerabilities

5. OSV.dev: package plus version in, vulns out (Google)

OSV.dev is Google's Open Source Vulnerabilities service. Instead of a CVE ID, you hand it a package and a version, and it hands back everything known to be wrong with that exact release. No key.

# runnable, read-only
curl -X POST "https://api.osv.dev/v1/query" \
  -H "Content-Type: application/json" \
  -d '{"package":{"ecosystem":"Maven","name":"org.apache.logging.log4j:log4j-core"},"version":"2.14.0"}'
Enter fullscreen mode Exit fullscreen mode 
{"vulns":[
  {"id":"GHSA-3pxv-7cmr-fjr4","summary":"Apache Log4j Core: Silent log event loss in XmlLayout ..."},
  {"id":"GHSA-jfh8-c2jp-5v3q","summary":"Remote code injection in Log4j"},
  {"id":"GHSA-7rjr-3q55-vv33","summary":"Incomplete fix for Apache Log4j vulnerability"},
  ... 7 total ...
]}
Enter fullscreen mode Exit fullscreen mode

Seven advisories for log4j-core:2.14.0. You can also fetch a single advisory by ID:

# runnable, read-only
curl "https://api.osv.dev/v1/vulns/GHSA-jfh8-c2jp-5v3q"
Enter fullscreen mode Exit fullscreen mode 
{"id":"GHSA-jfh8-c2jp-5v3q","summary":"Remote code injection in Log4j",
 "details":"# Summary\n\nLog4j versions prior to 2.16.0 are subject to a remote code execution vulnerability via the ldap JN..."}
Enter fullscreen mode Exit fullscreen mode

OSV aggregates GHSA, PyPI, npm, crates, Go, and more into one schema. It is a separate Google-hosted endpoint (api.osv.dev), not the GitHub API. That distinction matters, and I explain why in the "why not" section below.

When to use it: software composition analysis. Feed it a lockfile's worth of packages and versions and get a vuln list back, keyless, at scale.

Group C: decide what to patch first (the part everyone skips)

This is the group the flat "10 CVE APIs" lists never talk about, and it is the whole reason I wrote this. Looking a CVE up is easy. Deciding which of a long list to fix first is the job. Two free feeds answer it.

6. FIRST EPSS: the odds it gets exploited

EPSS is the Exploit Prediction Scoring System, run by FIRST. It gives every CVE a probability, from 0 to 1, that it will be exploited in the next 30 days. That is a different question from CVSS, which measures how bad exploitation would be if it happened. No key, and the response literally says so.

# runnable, read-only
curl "https://api.first.org/data/v1/epss?cve=CVE-2021-44228"
Enter fullscreen mode Exit fullscreen mode 
{"status":"OK","status-code":200,"version":"1.0","access":"public","total":1,"offset":0,"limit":100,
 "data":[{"cve":"CVE-2021-44228","epss":"0.999990000","percentile":"1.000000000","date":"2026-07-02"}]}
Enter fullscreen mode Exit fullscreen mode

Log4Shell scores 0.99999, percentile 1.0, the top of the entire catalog. The move that makes this actionable is the multi-query. Pass your whole list and sort by risk:

# runnable, read-only
curl "https://api.first.org/data/v1/epss?cve=CVE-2021-44228,CVE-2014-0160&order=epss-desc"
Enter fullscreen mode Exit fullscreen mode

That sorts your open CVEs by the odds each one gets exploited, descending. That ordering, not the CVSS ordering, is your patch queue.

When to use it: ranking a backlog. A CVSS 9 with an EPSS of 0.02 can wait behind a CVSS 6 with an EPSS of 0.7.

7. CISA KEV: what is already being exploited

EPSS gives you probability. CISA KEV gives you confirmed fact. The Known Exploited Vulnerabilities catalog is the US government's list of CVEs seen in real attacks. If a CVE is in KEV, exploitation is not a prediction, it is happening.

# runnable, read-only
curl "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json"
Enter fullscreen mode Exit fullscreen mode 
{"title":"CISA Catalog of Known Exploited Vulnerabilities",
 "catalogVersion":"2026.07.01","dateReleased":"2026-07-01T19:00:06.9016Z","count":1631,
 "vulnerabilities":[{"cveID":"CVE-2026-45659","vendorProject":"Microsoft","product":"SharePoint Server",
   "vulnerabilityName":"Microsoft SharePoint Server Deserialization of Untrusted Data Vulnerability",
   "dateAdded":"2026-07-01","knownRansomwareCampaignUse":"Unknown"}]}
Enter fullscreen mode Exit fullscreen mode

Be honest about what this is: not a queryable API, a single JSON feed. It was 1.5 MB and count 1631 on July 1, 2026. You download the whole thing, build a set of CVE IDs, and check membership locally (cve_id in kev_set). Refresh it once a day. Pairing EPSS (probability) with KEV (confirmed) is your keyless triage filter, and Log4Shell sits in both.

When to use it: the top of every patch queue. Anything of yours that appears in KEV jumps the line, full stop.

Group D: find exposure by IP (not by CVE, by target)

8. Shodan InternetDB: one IP in, ports and CVEs out

The first three groups start from a CVE or a package. This one starts from a target. InternetDB is Shodan's free, keyless front end: give it an IP, get back open ports, detected software, and matched CVEs. The full paid Shodan needs a key. This slice does not.

# runnable, read-only. Scan only IPs you own or the public test host below.
curl "https://internetdb.shodan.io/45.33.32.156"
Enter fullscreen mode Exit fullscreen mode 
{"cpes":["cpe:/a:ntp:ntp:3","cpe:/a:openbsd:openssh:6.6.1p1",
  "cpe:/a:apache:http_server:2.4.7","cpe:/o:canonical:ubuntu_linux"],
 "hostnames":["scanme.nmap.org"],"ip":"45.33.32.156",
 "ports":[22,80,123,31337],"tags":["cloud"],
 "vulns":["CVE-2021-32786","CVE-2017-3167","CVE-2024-43204","CVE-2007-4723","CVE-2022-22720","CVE-2014-0118", ... 120 total ...]}
Enter fullscreen mode Exit fullscreen mode

That IP is scanme.nmap.org, the host Nmap runs specifically so people can test scanners against it legally. One keyless line returned 120 CVEs and an ancient OpenSSH 6.6.1p1 on port 22. Now the same call against Google DNS:

// curl https://internetdb.shodan.io/8.8.8.8
{"cpes":[],"hostnames":["dns.google"],"ip":"8.8.8.8","ports":[53,443],"tags":[],"vulns":[]}
Enter fullscreen mode Exit fullscreen mode

Zero vulns. Here is the trap I want you to avoid: an empty vulns array does not mean "safe." InternetDB matches CVEs against service banners, it does not actively test anything. Empty means "no banner-based match," which is a much weaker statement. Treat it as a fast first look, never as a clean bill of health.

When to use it: enriching a list of IPs you own with open ports and a candidate CVE list, before you decide what deserves a real scan. Scan only your own IPs or scanme.nmap.org. There is a rate limit.

Bonus: the root-cause API, endoflife.date

This one is not a vulnerability feed, so I am listing it as a bonus, not a ninth API. But software past its end-of-life stops getting patches, which is the root cause of why CVEs sit open. Checking "is this runtime still supported" complements the CVE lookups above. No key.

# runnable, read-only
curl "https://endoflife.date/api/python.json"
Enter fullscreen mode Exit fullscreen mode 
[{"cycle":"3.14","releaseDate":"2025-10-07","eol":"2030-10-31","latest":"3.14.6","support":"2027-10-01"},
 {"cycle":"3.13","releaseDate":"2024-10-07","eol":"2029-10-31","latest":"3.13.14","support":"2026-10-01"}, ...]
Enter fullscreen mode Exit fullscreen mode

Small honesty note. My source analysis had this example showing Python 3.13 as the newest cycle. By the time I re-ran it on July 3, 2026, Python 3.14 was out (latest 3.14.6). That is exactly why every response in this post is dated and why I keep saying: run the curl yourself. Free endpoints drift under you.

Honorable mentions: free tier, but you need a free key (no card)

Three services have a genuinely free tier without a credit card, but they want a free key or a signup, so they miss the keyless bar. I did not live-test their quotas, so I am not quoting numbers. Check the current limits on their pages: the NVD free API key (lifts the rate cap from ~5 to 50 req/30s, worth it if you hit the wall), Vulners (vulners.com), and VulnCheck Community (vulncheck.com), which offers free CVE, KEV, and exploit data after registration.

Why some "free" vulnerability APIs did not make the cut

Keyless is a promise the network sometimes breaks. Here is what failed when I tested on July 3, 2026, so you do not waste an afternoon:

  • Vulners returned HTTP 403 with a Cloudflare "Just a moment..." bot challenge on the unauthenticated call, and it requires an API key anyway. Not keyless.
  • VulnCheck returned HTTP 401 {"error":true,"errors":["unauthorized"]} without a token. Free, but registration and a token first.
  • GitHub Advisory Database actually worked keyless: api.github.com/advisories?cve_id=CVE-2021-44228 returned HTTP 200 and one advisory, GHSA-jfh8-c2jp-5v3q. I left it off for two honest reasons. First, I covered the GitHub API in my last-but-one keyless roundup and I do not repeat providers across these lists. Second, unauthenticated it caps at 60 requests per hour. OSV.dev (number 5) serves the same GHSA data keyless without that cap, so it earned the slot instead. Note the advisory ID GitHub returned is the identical one OSV gave me: same data, no GitHub limit.
  • Commercial scanners (Snyk, Qualys, Tenable) are paid or key-gated by design, outside the "no key" line.

Keeping these alive under real traffic

The failure mode with free feeds is never the first call, it is the ten-thousandth. A few habits keep you in business:

Download KEV, do not poll it. KEV is one 1.5 MB feed. Pull it once a day into a set of CVE IDs and check membership locally. Do not fetch it per CVE.

Respect the NVD ceiling. About 5 requests per 30 seconds without a key. Put a queue and a sleep between calls, or take the free key and get 50. A burst that passes today is not a guarantee.

Cache the CVE records. The same CVE shows up across many targets. Hash the ID, store the record, reuse it. NVD, CIRCL, and the distro APIs all reward a cache.

Stay on the right side of the scan. InternetDB is passive lookup, not a scanner, but the discipline still holds: only query IPs you own or the explicit test host scanme.nmap.org. This is triage data, not permission.

This is context for how I think about it, not a claim of scale. I build web-scraping and data-enrichment tool layers, 2,190 runs across 32 actors in production, and the output is always a list of things (domains, IPs, packages) that needs enrichment columns. Geocoding was last week's column. Security posture is this one. Same keyless, no-card enrichment layer, different question.

FAQ

What is the best free CVE API with no API key?
For the canonical record, NVD (NIST) is the reference, with CIRCL Vulnerability-Lookup as a faster keyless second source. For vendor-specific severity and patch state, use Red Hat's or Ubuntu's security API for the distro you actually run. All four are keyless.

How do I check if a CVE is being exploited for free?
Two keyless feeds together. FIRST EPSS (api.first.org/data/v1/epss?cve=) gives the probability of exploitation in the next 30 days. CISA KEV (a downloadable JSON feed) lists CVEs confirmed exploited in the wild. If a CVE is in KEV, patch it first.

Can I scan a package for vulnerabilities without an API key?
Yes. OSV.dev takes a POST to /v1/query with an ecosystem, package name, and version, and returns every known advisory for that release. No key. It aggregates GHSA, PyPI, npm, crates, Go, and more.

Is the NVD API free, and does it need a key?
It is free and keyless, but rate-limited to roughly 5 requests per 30 seconds without a key. A free API key (no card) raises that to 50. Verify the current limit on the NVD developers page before a bulk job.

How do I find CVEs for an IP address for free?
Shodan InternetDB: curl https://internetdb.shodan.io/<ip> returns open ports, detected software, and matched CVEs with no key. It is banner-based, not an active scan, so an empty result is not proof of safety, and you should query only IPs you own or scanme.nmap.org.

Written by Aleksei Spinov. I build web-scraping and data-enrichment tool layers, currently 2,190 runs across 32 actors in production. Every API above was re-verified with a live curl (HTTP 200, real response) on July 3, 2026 before publishing; responses are trimmed, not paraphrased. EPSS scores, KEV counts, and CVSS numbers drift, so run the curl yourself before you wire one into anything that matters. Drafted with an AI assistant, fact-checked and edited by me.

Follow for the next batch of keyless tools I test for the enrichment layer. And tell me: what is your keyless triage stack, do you gate on an EPSS threshold, KEV membership, or both, and where has it given you false calm? I read every comment.

Top comments (0)