Developer Tools

Vulnerability & Dependency Intelligence API API

The Vulnerability & Dependency Intelligence API returns OSV.dev-powered vulnerability data as clean JSON.

7 actionsLive JSON1,000 free creditsMCP-ready

🤖 Using an AI assistant? Copy this link into ChatGPT / Claude / Cursor — it reads every endpoint and parameter instantly and tells you if this API fits your use case.

The primary package_vulns endpoint returns a package's known vulnerabilities with a count and a severity summary (critical, high, moderate, low), and you can pull a vuln_detail, search advisories, check the CISA KEV (known-exploited) list, look up exploits and batch many packages. It is built for supply-chain security, dependency review and patch-prioritization workflows that need actionable vulnerability intelligence without stitching feeds together. One ReefAPI key, one shared credit pool, the standard envelope.

Live example

Real request and response JSON

Captured from the indexed primary action, package_vulns, on Jul 18, 2026, 5:19 PM UTC.

Captured request

{
  "method": "POST",
  "url": "https://api.reefapi.com/vuln-intel/v1/package_vulns",
  "headers": {
    "x-api-key": "$REEF_KEY",
    "content-type": "application/json"
  },
  "body": {
    "package": "org.apache.logging.log4j:log4j-core",
    "ecosystem": "Maven",
    "version": "2.14.1"
  }
}

Captured response

{
  "ok": true,
  "meta": {
    "api": "vuln-intel",
    "endpoint": "package_vulns",
    "mode": "live",
    "latency_ms": 1017.1,
    "record_count": 7,
    "bytes": 53027,
    "cache_hit": false,
    "query_kind": "package",
    "highest_severity": "critical"
  },
  "data": {
    "package": "org.apache.logging.log4j:log4j-core",
    "ecosystem": "Maven",
    "version": "2.14.1",
    "commit": null,
    "vuln_count": 7,
    "severity_summary": {
      "by_severity": {
        "critical": 2,
        "high": 1,
        "moderate": 4,
        "low": 0,
        "unknown": 0
      },
      "highest_severity": "critical",
      "total": 7
    },
    "vulnerabilities": [
      {
        "id": "GHSA-3pxv-7cmr-fjr4",
        "aliases": [
          "CVE-[redacted-phone]"
        ],
        "cve_ids": [
          "CVE-[redacted-phone]"
        ],
        "summary": "Apache Log4j Core: Silent log event loss in XmlLayout due to unescaped XML 1.0 forbidden characters",
        "details": "Apache Log4j Core's [`XmlLayout`](https://logging.apache.org/log4j/2.x/manual/layouts.html#XmlLayout), in versions up to and including 2.25.3, fails to sanitize characters forbidden by the [XML 1.0 specification](https://www.w3.org/TR/xml/#charsets), producing invalid XML output whenever a log message or MDC value contains such characters.\n\nThe impact depends on the StAX implementation in use:\n\n  *  **JRE built-in StAX**: Forbidden characters are silently written to the output, producing malformed XML. Conforming parsers must reject such documents with a fatal error, which may cause downstream",
        "severity_label": "MODERATE",
        "cvss_vector": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:L/SA:N",
        "cvss_type": "CVSS_V4",
        "cvss_base_score": null,
        "published": "[redacted-phone]T18:31:17Z",
        "modified": "[redacted-phone]T11:29:[redacted-phone]Z",
        "withdrawn": null,
        "related": [
          "CGA-wqhw-vh22-jwgm"
        ],
        "affected": [
          {
            "package": "[trimmed-depth]",
            "ecosystem": "[trimmed-depth]",
            "purl": "[trimmed-depth]",
            "introduced": "[trimmed-depth]",
            "fixed": "[trimmed-depth]",
            "last_affected": "[trimmed-depth]",
            "versions_listed": "[trimmed-depth]"
          },
          {
            "package": "[trimmed-depth]",
            "ecosystem": "[trimmed-depth]",
            "purl": "[trimmed-depth]",
            "introduced": "[trimmed-depth]",
            "fixed": "[trimmed-depth]",
            "last_affected": "[trimmed-depth]",
            "versions_listed": "[trimmed-depth]"
          }
        ],
        "fixed_versions": [
          "2.25.4"
        ],
        "references": [
          {
            "type": "[trimmed-depth]",
            "url": "[trimmed-depth]"
          },
          {
            "type": "[trimmed-depth]",
            "url": "[trimmed-depth]"
          },
          {
            "type": "[trimmed-depth]",
            "url": "[trimmed-depth]"
          }
        ],
        "database_specific": {
          "nvd_published_at": "[redacted-phone]T16:16:31Z",
          "severity": "MODERATE",
          "cwe_ids": [
            "[trimmed-depth]"
          ],
          "github_reviewed_at": "[redacted-phone]T21:16:41Z",
          "github_reviewed": true
        },
        "schema_version": "1.7.5",
        "source": "osv.dev"
      },
      {
        "id": "GHSA-6hg6-v5c8-fphq",
        "aliases": [
          "CVE-[redacted-phone]"
        ],
        "cve_ids": [
          "CVE-[redacted-phone]"
        ],
        "summary": "Apache Log4j Core: `verifyHostName` attribute silently ignored in TLS configuration",
        "details": "The fix for  CVE-[redacted-phone] was incomplete: it addressed hostname verification only when enabled via the  [`log4j2.sslVerifyHostName`](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName) system property, but not when configured through the [`verifyHostName`](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName) attribute of the `<Ssl>` element.\n\nAlthough the `verifyHostName` configuration attribute was introduced in Log4j Core 2.12.0, it was silently ignored in all versions through 2.25.3, leaving ",
        "severity_label": "MODERATE",
        "cvss_vector": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N",
        "cvss_type": "CVSS_V4",
        "cvss_base_score": null,
        "published": "[redacted-phone]T18:31:17Z",
        "modified": "[redacted-phone]T12:29:[redacted-phone]Z",
        "withdrawn": null,
        "related": [
          "CGA-99gg-5485-cvhj"
        ],
        "affected": [
          {
            "package": "[trimmed-depth]",
            "ecosystem": "[trimmed-depth]",
            "purl": "[trimmed-depth]",
            "introduced": "[trimmed-depth]",
            "fixed": "[trimmed-depth]",
            "last_affected": "[trimmed-depth]",
            "versions_listed": "[trimmed-depth]"
          },
          {
            "package": "[trimmed-depth]",
            "ecosystem": "[trimmed-depth]",
            "purl": "[trimmed-depth]",
            "introduced": "[trimmed-depth]",
            "fixed": "[trimmed-depth]",
            "last_affected": "[trimmed-depth]",
            "versions_listed": "[trimmed-depth]"
          }
        ],
        "fixed_versions": [
          "2.25.4"
        ],
        "references": [
          {
            "type": "[trimmed-depth]",
            "url": "[trimmed-depth]"
          },
          {
            "type": "[trimmed-depth]",
            "url": "[trimmed-depth]"
          },
          {
            "type": "[trimmed-depth]",
            "url": "[trimmed-depth]"
          }
        ],
        "database_specific": {
          "github_reviewed_at": "[redacted-phone]T00:11:55Z",
          "github_reviewed": true,
          "nvd_published_at": "[redacted-phone]T16:16:30Z",
          "severity": "MODERATE",
          "cwe_ids": [
            "[trimmed-depth]"
          ]
        },
        "schema_version": "1.7.5",
        "source": "osv.dev"
      },
      {
        "id": "GHSA-7rjr-3q55-vv33",
        "aliases": [
          "CVE-[redacted-phone]"
        ],
        "cve_ids": [
          "CVE-[redacted-phone]"
        ],
        "summary": "Incomplete fix for Apache Log4j vulnerability",
        "details": "# Impact\n\nThe fix to address [CVE-[redacted-phone]](https://nvd.nist.gov/vuln/detail/CVE-[redacted-phone]) in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. This could allow attackers with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) to craft malicious input data using a JNDI Lookup pattern resulting in a remote code execution (RCE) attack. \n\n## Affected packages\nOnly the `org.apache.loggi",
        "severity_label": "CRITICAL",
        "cvss_vector": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H/E:H",
        "cvss_type": "CVSS_V3",
        "cvss_base_score": null,
        "published": "[redacted-phone]T18:01:28Z",
        "modified": "[redacted-phone]T19:37:[redacted-phone]Z",
        "withdrawn": null,
        "related": [],
        "affected": [
          {
            "package": "[trimmed-depth]",
            "ecosystem": "[trimmed-depth]",
            "purl": "[trimmed-depth]",
            "introduced": "[trimmed-depth]",
            "fixed": "[trimmed-depth]",
            "last_affected": "[trimmed-depth]",
            "versions_listed": "[trimmed-depth]"
          },
          {
            "package": "[trimmed-depth]",
            "ecosystem": "[trimmed-depth]",
            "purl": "[trimmed-depth]",
            "introduced": "[trimmed-depth]",
            "fixed": "[trimmed-depth]",
            "last_affected": "[trimmed-depth]",
            "versions_listed": "[trimmed-depth]"
          },
          {
            "package": "[trimmed-depth]",
            "ecosystem": "[trimmed-depth]",
            "purl": "[trimmed-depth]",
            "introduced": "[trimmed-depth]",
            "fixed": "[trimmed-depth]",
            "last_affected": "[trimmed-depth]",
            "versions_listed": "[trimmed-depth]"
          }
        ],
        "fixed_versions": [
          "2.16.0",
          "2.12.2",
          "1.9.2"
        ],
        "references": [
          {
            "type": "[trimmed-depth]",
            "url": "[trimmed-depth]"
          },
          {
            "type": "[trimmed-depth]",
            "url": "[trimmed-depth]"
          },
          {
            "type": "[trimmed-depth]",
            "url": "[trimmed-depth]"
          }
        ],
        "database_specific": {
          "nvd_published_at": "[redacted-phone]T19:15:00Z",
          "severity": "CRITICAL",
          "cwe_ids": [
            "[trimmed-depth]",
            "[trimmed-depth]"
          ],
          "github_reviewed_at": "[redacted-phone]T17:55:00Z",
          "github_reviewed": true
        },
        "schema_version": "1.7.3",
        "source": "osv.dev"
      }
    ]
  }
}

Actions

What the Vulnerability & Dependency Intelligence API API does

Action	Description	Concrete use case	Key params
package_vulns	All known vulnerabilities affecting a package (by name+ecosystem, optionally pinned to an installed version) OR a git commit — via OSV.dev. The dependency-audit core.	Ops teams call package_vulns to get all known vulnerabilities affecting a package (by name+ecosystem, optionally pinned to an ins….	package, ecosystem, version, commit
vuln_detail	Full detail for one vulnerability by OSV id, GHSA id, or CVE id. OSV is the base record; if it resolves to a GHSA the response is enriched with GitHub's numeric CVSS base score, EPSS exploitation probability, and CWEs.	Developer tools call vuln_detail to get full detail for one vulnerability by OSV id, GHSA id, or CVE id.	id
advisory_search	Search the GitHub Advisory Database (GHSA) by ecosystem, severity, CVE, free text, type. Cursor-paginated (meta.next_cursor).	Validation workflows call advisory_search to search the GitHub Advisory Database (GHSA) by ecosystem, severity, CVE, free text, type.	ecosystem, severity, cve_id, query, type, ...
kev_check	Is a CVE in the CISA Known-Exploited-Vulnerabilities catalog (actively exploited in the wild)? Returns the KEV entry when listed.	Data-quality teams call kev_check to get is a CVE in the CISA Known-Exploited-Vulnerabilities catalog (actively exploited in the wild)?.	cve_id
kev_list	Browse / filter the full CISA KEV catalog by vendor, product, or ransomware flag, with page pagination.	Ops teams call kev_list to get browse / filter the full CISA KEV catalog by vendor, product, or ransomware flag, with page p….	vendor, product, ransomware, page, per_page
exploits	Public exploit / PoC lookup for a CVE via the Exploit-DB (Offensive Security) database (keyless, CVE-indexed). Answers 'is there a weaponized public exploit?' — has_public_exploit + each entry's edb_id, type (remote/local/webapps/dos), platform, verified flag, date_published, and deep links (exploit_db_url + upstream source_url).	Developer tools call exploits to get public exploit / PoC lookup for a CVE via the Exploit-DB (Offensive Security) database (keyle….	cve_id, verified_only
batch	Bulk-scan up to 100 package/commit queries in one call (OSV querybatch), each hydrated to full vulnerability detail by default.	Validation workflows call batch to get bulk-scan up to 100 package/commit queries in one call (OSV querybatch), each hydrated to ful….	queries, hydrate

Code samples

Call package_vulns from your stack

curl -X POST https://api.reefapi.com/vuln-intel/v1/package_vulns \
  -H "x-api-key: $REEF_KEY" \
  -H "content-type: application/json" \
  -d '{"package":"org.apache.logging.log4j:log4j-core","ecosystem":"Maven","version":"2.14.1"}'

import requests

r = requests.post(
    "https://api.reefapi.com/vuln-intel/v1/package_vulns",
    headers={"x-api-key": REEF_KEY},
    json={
  "package": "org.apache.logging.log4j:log4j-core",
  "ecosystem": "Maven",
  "version": "2.14.1"
},
)
print(r.json()["data"])

const res = await fetch("https://api.reefapi.com/vuln-intel/v1/package_vulns", {
  method: "POST",
  headers: {
    "x-api-key": process.env.REEF_KEY,
    "content-type": "application/json",
  },
  body: JSON.stringify({
  "package": "org.apache.logging.log4j:log4j-core",
  "ecosystem": "Maven",
  "version": "2.14.1"
}),
});
const { ok, data, meta, error } = await res.json();

MCP one-liner

Ask your MCP-connected assistant: call reefapi.vuln-intel.package_vulns with {"package":"org.apache.logging.log4j:log4j-core","ecosystem":"Maven","version":"2.14.1"}.

Use cases

Who uses this API and why

Security teams call package_vulns to find and rank vulnerabilities across a project's dependencies.
Patch-prioritization tools use kev_check to flag dependencies with known-exploited CVEs first.
Compliance workflows use advisory_search and vuln_detail to document and track remediation.

FAQ

Questions developers ask before integrating

What is the Vulnerability & Dependency Intelligence API API?

Vulnerability & Dependency Intelligence API API is a ReefAPI endpoint group for vulnerability & dependency intelligence api It returns live JSON through POST requests under /vuln-intel/v1.

Is the Vulnerability & Dependency Intelligence API API free to try?

Yes. ReefAPI starts with 1,000 free credits, no card required. Vulnerability & Dependency Intelligence API calls use the same shared credit balance as every other ReefAPI engine.

Do I need a Vulnerability & Dependency Intelligence API login or account?

No login to Vulnerability & Dependency Intelligence API is needed for the API response. You call ReefAPI with your x-api-key header, and the playground can run live examples before you create a production key.

How fresh is the Vulnerability & Dependency Intelligence API data?

The page example is captured from a live package_vulns call, and production requests fetch live data through ReefAPI rather than a static sample.

How many credits does the Vulnerability & Dependency Intelligence API API use?

Vulnerability & Dependency Intelligence API actions currently cost 1 credit per successful call. Failed or blocked calls are free, and all APIs draw from one credit pool.

Can I call Vulnerability & Dependency Intelligence API from an AI assistant or MCP client?

Yes. Connect ReefAPI once through MCP and your assistant can call vuln-intel actions with the same key, credit pool and JSON envelope used by normal REST requests.

Is the Vulnerability & Dependency Intelligence API API a Vulnerability & Dependency Intelligence API scraper?

It is the managed alternative to a DIY Vulnerability & Dependency Intelligence API scraper. Instead of building and maintaining your own scraper — proxies, headless browsers, captcha and constant breakage — you call one ReefAPI endpoint and get the same vulnerability & dependency intelligence api back as clean JSON.

Why does my Vulnerability & Dependency Intelligence API scraper keep getting blocked?

Most Vulnerability & Dependency Intelligence API scrapers break on anti-bot defenses, rate limits and IP bans that need rotating residential proxies and browser fingerprinting to clear. ReefAPI handles all of that for you — no proxies, no captchas, no maintenance — and returns live JSON. Blocked or failed calls are free.

docs / vuln-intel

Vulnerability & Dependency Intelligence API

base /vuln-intel/v17 endpoints

post/vuln-intel/v1/package_vulns1 credit

All known vulnerabilities affecting a package (by name+ecosystem, optionally pinned to an installed version) OR a git commit — via OSV.dev. The dependency-audit core.

Parameter		Allowed / range	Description
package	required	—	Package name as published in its registry (npm 'lodash', PyPI 'django', Maven 'group:artifact' e.g. 'org.apache.logging.log4j:log4j-core', Go import path). Required unless you pass `commit` instead.
ecosystem	required	alpine · android · bitnami · cargo · composer · crates.io · debian · githubactions · go · hex · maven · npm · nuget · packagist · pub · pypi · rubygems · swifturl · ubuntu	Package ecosystem / registry. Case-insensitive; common aliases map (cargo->crates.io, pip/python->PyPI is via the 'pypi' key, composer->Packagist). Required with `package` (omit when querying by `commit`).
version	optional	—	Exact installed version to test (e.g. '2.14.1', '4.17.15'). Omit to return ALL known vulnerabilities for the package across every version.
commit	optional	—	Git commit hash to query instead of package+version+ecosystem (OSV resolves which vulns affect that exact source revision).

Try in playground →

post/vuln-intel/v1/vuln_detail1 credit

Full detail for one vulnerability by OSV id, GHSA id, or CVE id. OSV is the base record; if it resolves to a GHSA the response is enriched with GitHub's numeric CVSS base score, EPSS exploitation probability, and CWEs.

Parameter		Allowed / range	Description
id	required	—	A vulnerability id: OSV id (GHSA-…, PYSEC-…, GO-…, RUSTSEC-…) or a CVE (CVE-2021-44228). CVE ids are resolved via OSV's alias index. Case-insensitive.

Try in playground →

post/vuln-intel/v1/advisory_search1 credit

Search the GitHub Advisory Database (GHSA) by ecosystem, severity, CVE, free text, type. Cursor-paginated (meta.next_cursor).

Parameter		Allowed / range	Description
ecosystem	optional	actions · composer · erlang · go · maven · npm · nuget · other · pip · pub · rubygems · rust · swift	Filter advisories by GitHub ecosystem token (note GitHub's spelling: 'pip' for Python, 'rust' for crates, 'actions' for GitHub Actions).
severity	optional	low · medium · high · critical	Filter advisories by qualitative severity.
cve_id	optional	—	Return only the advisory(ies) for this exact CVE id.
query	optional	—	Free-text search across advisory summary/description.
type	optional	reviewed · unreviewed · malware	Advisory review state. 'reviewed' (default) = GitHub-curated; 'malware' = malicious-package advisories.
sort	optional	published · updated	Sort field for the advisory list.
direction	optional	desc · asc	Sort direction.
per_page = 30	optional	1–100	Results per page (1-100, default 30). Larger values are clamped.
cursor	optional	—	Opaque pagination cursor for the next page of advisories — pass the value from meta.next_cursor. (GHSA paginates by cursor, not page number.)

Try in playground →

post/vuln-intel/v1/kev_check1 credit

Is a CVE in the CISA Known-Exploited-Vulnerabilities catalog (actively exploited in the wild)? Returns the KEV entry when listed.

Parameter		Allowed / range	Description
cve_id	required	—	The CVE id to look up in the CISA Known-Exploited-Vulnerabilities catalog. Case-insensitive.

Try in playground →

post/vuln-intel/v1/kev_list1 credit

Browse / filter the full CISA KEV catalog by vendor, product, or ransomware flag, with page pagination.

Parameter		Allowed / range	Description
vendor	optional	—	Filter KEV entries by vendor/project (substring, case-insensitive).
product	optional	—	Filter KEV entries by product (substring, case-insensitive).
ransomware	optional	Known · Unknown	Filter KEV entries by whether the CVE is known-used in ransomware campaigns (CISA's knownRansomwareCampaignUse field).
page = 1	optional	1–	1-based page number for the KEV list. Page forward with meta.next_page.
per_page = 30	optional	1–100	Results per page (1-100, default 30). Larger values are clamped.

Try in playground →

post/vuln-intel/v1/exploits1 credit

Public exploit / PoC lookup for a CVE via the Exploit-DB (Offensive Security) database (keyless, CVE-indexed). Answers 'is there a weaponized public exploit?' — has_public_exploit + each entry's edb_id, type (remote/local/webapps/dos), platform, verified flag, date_published, and deep links (exploit_db_url + upstream source_url).

Parameter		Allowed / range	Description
cve_id	required	—	The CVE id to look up in the Exploit-DB (Offensive Security) public exploit/PoC database. Case-insensitive. Returns every exploit row whose 'codes' column references this CVE.
verified_only = false	optional	—	If true, return only Exploit-DB entries marked verified (reproduced by the Exploit-DB team). Default false = all entries.

Try in playground →

post/vuln-intel/v1/batch1 credit

Bulk-scan up to 100 package/commit queries in one call (OSV querybatch), each hydrated to full vulnerability detail by default.

Parameter		Allowed / range	Description
queries	required	—	Array of up to 100 query objects. Each is either {package, ecosystem, version?} or {commit}. Returns one result group per query (order preserved), each hydrated to full vulnerability detail.
hydrate = true	optional	—	If true (default) each batch hit is expanded to the full normalized vulnerability via OSV /vulns/{id}. Set false for a faster id-only response (returns {id, modified} per hit).

Try in playground →

Example request · package_vulns

curl -X POST https://api.reefapi.com/vuln-intel/v1/package_vulns \
  -H "x-api-key: $REEF_KEY" \
  -H "content-type: application/json" \
  -d '{"package":"org.apache.logging.log4j:log4j-core","ecosystem":"Maven","version":"2.14.1"}'

Response shape

{
  "ok": true,
  "data": { /* the result */ },
  "meta": {
    "latency_ms": 240,
    "record_count": 12,
    "completeness_pct": 100
  },
  "error": null
}