Is this exact version affected, and is anyone actually exploiting it
The Vulnerability & Dependency Intelligence API returns OSV.dev-powered vulnerability data as clean JSON.
7 active endpoints. Every call is 1 credit.
- POST/vuln-intel/v1/package_vulns
- POST/vuln-intel/v1/vuln_detail
- POST/vuln-intel/v1/advisory_search
- POST/vuln-intel/v1/kev_check
- POST/vuln-intel/v1/kev_list
- POST/vuln-intel/v1/exploits
- POST/vuln-intel/v1/batch
What Vulnerability & Dependency Intelligence endpoints does ReefAPI ship?
7 live read endpoints. Read-only data API: no writes, no account actions, no dashboard access on the target site.
Vulnerability & Dependency Intelligence API
3 of 7 endpoints, ready to run
Advisories affecting one package at one version, each with its identifiers, CVE aliases, summary, severity and affected ranges — plus a severity summary across all of them.
{ "ok": true, "meta": { "api": "vuln-intel", "endpoint": "package_vulns", "mode": "live", "latency_ms": 935, "record_count": 7, "cache_hit": false }, "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-2026-34480" ], "cve_ids": [ "CVE-2026-34480" ], "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 log-processing systems to drop the affected records.\n * **Alternative StAX implementations** (e.g., [Woodstox](https://github.com/FasterXML/woodstox), a transitive dependency of the Jackson XML Dataformat module): An exception is thrown during the logging call, and the log event is never delivered to its intended appender, only to Log4j's internal status logger.\n\nUsers are advised to upgrade to Apache Log4j Core 2.25.4, which corrects this issue by sanitizing forbidden characters before XML output.", "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": "2026-04-10T18:31:17Z", "modified": "2026-04-16T11:29:10.536806482Z", "withdrawn": null, "related": [ "CGA-wqhw-vh22-jwgm" ], "affected": [ { "package": "org.apache.logging.log4j:log4j-core", "ecosystem": "Maven", "purl": "pkg:maven/org.apache.logging.log4j/log4j-core", "introduced": [ "2.0-alpha1" ], "fixed": [ "2.25.4" ], "last_affected": [], "versions_listed": 70 }, { "package": "org.apache.logging.log4j:log4j-core", "ecosystem": "Maven", "purl": "pkg:maven/org.apache.logging.log4j/log4j-core", "introduced": [ "3.0.0-alpha1" ], "fixed": [], "last_affected": [ "3.0.0-beta3" ], "versions_listed": 4 } ], "fixed_versions": [ "2.25.4" ], "references": [ { "type": "ADVISORY", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34480" }, { "type": "WEB", "url": "https://github.com/apache/logging-log4j2/pull/4077" }, { "type": "PACKAGE", "url": "https://github.com/apache/logging-log4j2" } ], "database_specific": { "nvd_published_at": "2026-04-10T16:16:31Z", "severity": "MODERATE", "cwe_ids": [ "CWE-116" ], "github_reviewed_at": "2026-04-10T21:16:41Z", "github_reviewed": true }, "schema_version": "1.7.5", "source": "osv.dev" }, { "id": "GHSA-6hg6-v5c8-fphq", "aliases": [ "CVE-2026-34477" ], "cve_ids": [ "CVE-2026-34477" ], "summary": "Apache Log4j Core: `verifyHostName` attribute silently ignored in TLS configuration", "details": "The fix for CVE-2025-68161 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 TLS connections vulnerable to interception regardless of the configured value.\n\nA network-based attacker may be able to perform a man-in-the-middle attack when all of the following conditions are met:\n\n * An SMTP, Socket, or Syslog appender is in use.\n * TLS is configured via a nested <Ssl> element.\n * The attacker can present a certificate issued by a CA trusted by the appender's configured trust store, or by the default Java trust store if none is configured.\n\nThis issue does not affect users of the HTTP appender, which uses a separate [`verifyHostname`](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#HttpAppender-attr-verifyHostName) attribute that was not subject to this bug and verifies host names by default.\n\nUsers are advised to upgrade to Apache Log4j Core 2.25.4, which corrects this issue.", "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": "2026-04-10T18:31:17Z", "modified": "2026-04-17T12:29:10.521430176Z", "withdrawn": null, "related": [ "CGA-99gg-5485-cvhj" ], "affected": [ { "package": "org.apache.logging.log4j:log4j-core", "ecosystem": "Maven", "purl": "pkg:maven/org.apache.logging.log4j/log4j-core", "introduced": [ "2.12.0" ], "fixed": [ "2.25.4" ], "last_affected": [], "versions_listed": 33 }, { "package": "org.apache.logging.log4j:log4j-core", "ecosystem": "Maven", "purl": "pkg:maven/org.apache.logging.log4j/log4j-core", "introduced": [ "3.0.0-alpha1" ], "fixed": [], "last_affected": [ "3.0.0-beta3" ], "versions_listed": 4 } ], "fixed_versions": [ "2.25.4" ], "references": [ { "type": "ADVISORY", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34477" }, { "type": "WEB", "url": "https://github.com/apache/logging-log4j2/pull/4075" }, { "type": "PACKAGE", "url": "https://github.com/apache/logging-log4j2" } ], "database_specific": { "github_reviewed": true, "nvd_published_at": "2026-04-10T16:16:30Z", "severity": "MODERATE", "cwe_ids": [ "CWE-297" ], "github_reviewed_at": "2026-04-14T00:11:55Z" }, "schema_version": "1.7.5", "source": "osv.dev" }, { "id": "GHSA-7rjr-3q55-vv33", "aliases": [ "CVE-2021-45046" ], "cve_ids": [ "CVE-2021-45046" ], "summary": "Incomplete fix for Apache Log4j vulnerability", "details": "# Impact\n\nThe fix to address [CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228) 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.logging.log4j:log4j-core` package is directly affected by this vulnerability. The `org.apache.logging.log4j:log4j-api` should be kept at the same version as the `org.apache.logging.log4j:log4j-core` package to ensure compatability if in use.\n\n# Mitigation\n\nLog4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default. This issue can be mitigated in prior releases (< 2.16.0) by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).\n\nLog4j 2.15.0 restricts JNDI LDAP lookups to localhost by default. Note that previous mitigations involving configuration such as to set the system property `log4j2.formatMsgNoLookups` to `true` do NOT mitigate this specific vulnerability.", "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": "2021-12-14T18:01:28Z", "modified": "2025-10-22T19:37:53.742023Z", "withdrawn": null, "related": [], "affected": [ { "package": "org.apache.logging.log4j:log4j-core", "ecosystem": "Maven", "purl": "pkg:maven/org.apache.logging.log4j/log4j-core", "introduced": [ "2.13.0" ], "fixed": [ "2.16.0" ], "last_affected": [], "versions_listed": 7 }, { "package": "org.apache.logging.log4j:log4j-core", "ecosystem": "Maven", "purl": "pkg:maven/org.apache.logging.log4j/log4j-core", "introduced": [ "0" ], "fixed": [ "2.12.2" ], "last_affected": [], "versions_listed": 39 }, { "package": "org.ops4j.pax.logging:pax-logging-log4j2", "ecosystem": "Maven", "purl": "pkg:maven/org.ops4j.pax.logging/pax-logging-log4j2", "introduced": [ "1.8.0" ], "fixed": [ "1.9.2" ], "last_affected": [], "versions_listed": 10 } ], "fixed_versions": [ "2.16.0", "2.12.2", "1.9.2" ], "references": [ { "type": "ADVISORY", "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-45046" }, { "type": "WEB", "url": "https://www.oracle.com/security-alerts/cpujul2022.html" }, { "type": "WEB", "url": "https://www.oracle.com/security-alerts/cpujan2022.html" } ], "database_specific": { "github_reviewed_at": "2021-12-14T17:55:00Z", "github_reviewed": true, "nvd_published_at": "2021-12-14T19:15:00Z", "severity": "CRITICAL", "cwe_ids": [ "CWE-502", "CWE-917" ] }, "schema_version": "1.7.3", "source": "osv.dev" } ] } }
How the Vulnerability & Dependency Intelligence API works
Vulnerability & Dependency Intelligence is a normal ReefAPI surface — the same four rules that hold for every other engine on the key.
No OAuth app, no request signing, no per-site account. One key covers all 184 engines.
Every route is a POST with a JSON body. Parameters are validated against the published schema before anything is charged.
Credits, not seats. Failed and blocked calls are never charged, and cache hits cost nothing.
One envelope everywhere. meta carries latency_ms, record_count and the endpoint that answered.
Deciding whether a finding is worth waking someone up for
A dependency scan produces dozens of criticals and no way to rank them. Severity is a property of the vulnerability; exploitation is a fact about the world.
{"package": "org.apache.logging.log4j:log4j-core", "ecosystem": "Maven", "version": "2.14.1"}Returns the advisories affecting that exact version, with a severity summary and the CVE aliases you need for the next step.
{"cve_id": "CVE-2021-44228"}For each critical. A CVE in the exploited catalogue comes back with the remediation deadline and whether ransomware crews are using it.
Two calls separate 'theoretically critical' from 'being used against people right now', which is the only ranking that survives contact with a limited engineering week.
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"}'{
"ok": true,
"data": { … },
"meta": {
"api": "vuln-intel",
"endpoint": "package_vulns",
"mode": "live",
"latency_ms": …,
"record_count": …
},
"error": null
}ID formats, ecosystem vocabularies, and where each number comes from
Three different databases sit behind this API and they do not agree on spelling or on scoring. package_vulns speaks OSV ecosystem names, advisory_search speaks GitHub's own tokens, and the numeric CVSS score only exists on the GitHub side. The table below is the vocabulary you need to get a hit on the first try.
| Input or field | Accepted format | Measured behavior |
|---|---|---|
| id, for vuln_detail | GHSA-xxxx-xxxx-xxxx, CVE-YYYY-NNNNN, PYSEC-, GO- or RUSTSEC- | case-insensitive, and a CVE is resolved through OSV's alias index; an id with no record returns NOT_FOUND rather than an empty object |
| ecosystem, for package_vulns | 19 tokens: alpine, android, bitnami, cargo, composer, crates.io, debian, githubactions, go, hex, maven, npm, nuget, packagist, pub, pypi, rubygems, swifturl, ubuntu | aliases are normalized in the response, so ecosystem cargo comes back as crates.io; an unlisted value such as javascript is rejected with INVALID_PARAM and the allowed list |
| ecosystem, for advisory_search | 13 GitHub tokens: actions, composer, erlang, go, maven, npm, nuget, other, pip, pub, rubygems, rust, swift | note pip rather than pypi and rust rather than cargo; the two actions do not share a vocabulary |
| Maven package name | group:artifact | org.apache.logging.log4j:log4j-core, not log4j-core on its own |
| severity_label | CRITICAL, HIGH, MODERATE, LOW | uppercase on the vulnerability record, while severity_summary.by_severity uses lowercase keys plus an unknown bucket for advisories with no rating |
| cvss_type | CVSS_V3 or CVSS_V4 | v4 vectors begin CVSS:4.0/AV:N/AC:L/AT:N/ and v3 vectors begin CVSS:3.1/AV:N/AC:L/PR:N/ |
| cvss_base_score | a number or null | null in package_vulns even when a vector is present; the number arrives through the ghsa block on vuln_detail, which returned 10.0 for Log4Shell |
| epss_percentage and epss_percentile | 0 to 1, a probability rather than a percent | CVE-2021-44228 measured 0.99999 and 1.0 despite the field name saying percentage |
| KEV catalog | catalog_version as a date string, catalog_count as an integer | measured 2026.08.26 with 1682 entries; known_ransomware_campaign_use is the string Known or Unknown, not a boolean |
CPE strings are not a first-class field. A CVE-level record exposes them under database_specific.unresolved_ranges as CPE_RANGE entries, and CVE-2021-44228 returned 150 of them, including cpe:2.3:a:apple:xcode:*:*:*:*:*:*:*:* with a fixed event of 13.3. Package-level matching goes through affected[].purl instead, for example pkg:maven/org.apache.logging.log4j/log4j-core.
What a zero means here, said out loud
Measured with a genuinely vulnerable version, a genuinely clean one, a misspelled name and a package that does not exist. The first row is the most important sentence on this page.
Advisory databases answer an unknown package exactly the way they answer a clean one: with an empty list. So a zero here carries an explicit caveat saying no advisory matched this name, ecosystem and version, and that an unrecognised name returns the same empty result. In a vulnerability API, an unqualified zero is the single most dangerous thing you can return, because a CI gate reads it as permission to ship.
Maven advisories are keyed on groupId:artifactId. A bare artifact id can never match anything, so instead of a confident empty result you get the caveat plus a hint naming the correct coordinate form. We found this the hard way: our own published example used a bare id and reported the exact version of log4j that Log4Shell is named after as having no vulnerabilities. The full coordinate returns seven advisories, highest severity critical.
The exploited-vulnerabilities check returns the government catalogue entry itself — the vendor, the product, the required action, the remediation due date, whether it is known to be used in ransomware, and the catalogue version and size the answer came from. Severity ranks theory; this ranks reality, and they disagree often enough to matter.
You pass the version you actually have and get back only the advisories that affect it, with the affected ranges and fixed versions on each. The alternative — parsing range expressions across half a dozen ecosystems yourself — is where most home-made scanners get it wrong.
Each advisory carries its GHSA id, its CVE ids and its other aliases together. Two tools reporting the same problem under different identifiers is a routine source of duplicate tickets, and the alias list is what collapses them.
What people build with Vulnerability & Dependency Intelligence
The jobs this data is most often used for.
endpoints
credit per call
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.
What Vulnerability & Dependency Intelligence data costs
The cheapest call here is 1 credit, so $15/mo (Pro) buys 10,000 of them — $1.50 per 1,000 credits. Credits roll over and never expire, and failed or blocked calls are not charged.
Full pricing →- 1,000 free credits on signup, no card
- One key, all 184 APIs, one credit pool
- Failed and blocked calls are never charged
- Credits roll over and never expire
Call it in two lines
Sign up, get 1,000 credits and one key that works on every engine. Then this is the whole protocol.
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"])Have a question? We got answers.
The questions people actually ask before wiring up Vulnerability & Dependency Intelligence.
Get a free key →Why is cvss_base_score null when the vector is right there?▾
Because package_vulns returns the raw OSV record, which carries the vector string but not a computed base score. A measured lodash advisory had cvss_vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L with cvss_base_score null, and a log4j-core advisory had a CVSS:4.0 vector with the same null. The number comes from GitHub's enrichment, which only vuln_detail performs. Sort a dependency audit on severity_label, then call vuln_detail on the ones you need a number for.
Does querying by CVE give the same record as querying by GHSA?▾
No, and the difference matters. vuln_detail for CVE-2021-44228 returned the CVE-level OSV record with summary null, affected[0].package, ecosystem and purl all null, and version ranges expressed as git commit hashes such as 38513a7d57343881f7bf58f37e67d6a87e0a47c5. The same call for GHSA-jfh8-c2jp-5v3q returned package org.apache.logging.log4j:log4j-core, ecosystem Maven, introduced 2.13.0 and fixed 2.15.0. Both responses carry the ghsa block with the readable summary, so use the GHSA id when you want package version ranges.
What does a package with no known vulnerabilities look like?▾
ok true with vuln_count 0, an empty vulnerabilities array, meta.record_count 0 and severity_summary.highest_severity null rather than the string none, with every by_severity bucket at 0. Measured on left-pad 1.3.0 in npm. There is no 404 for a clean package, so branch on vuln_count and treat highest_severity null as the clean marker.
Does pinning a version really change the answer?▾
Yes. log4j-core 2.14.1 in Maven returned 7 vulnerabilities with by_severity critical 2, high 1 and moderate 4, and highest_severity critical. Omitting version returns every vulnerability the package has ever had, which is the wrong list for an audit. A current release is not automatically clean either: lodash 4.17.21 still returned 3 open advisories with highest_severity high.
KEV, EPSS and Exploit-DB all sound like the same thing. What is the difference?▾
They are three separate claims. kev_check is CISA's binary in_kev flag with a date_added, a due_date for US federal agencies and a known_ransomware_campaign_use string. EPSS is a modeled probability between 0 and 1 that the CVE will be exploited. exploits queries Exploit-DB for code that actually exists. Log4Shell scored on all three: in_kev true added 2021-12-10 with ransomware Known, epss 0.99999, and exploit_count 3 including edb_id 50592. A CVE can sit in KEV with zero Exploit-DB rows, and the reverse happens too.
How is exploit_references different from the exploits action?▾
exploit_references is extracted from the advisory's own reference list by matching known PoC hosts such as exploit-db, packetstorm and metasploit, so it is only as complete as that advisory. meta.exploit_ref_count read 19 for the CVE record and 26 for the GHSA record of the same vulnerability, because the two records list different references. The exploits action queries Exploit-DB directly and returns edb_id, type (remote, local, webapps, dos), platform, author, date_published, a verified flag and both exploit_db_url and source_url. All three Log4Shell rows came back verified false.
How does pagination work, and is there a rate limit I can see?▾
The two list actions paginate differently. advisory_search is cursor-based: meta.next_cursor holds an opaque base64 string you pass back as cursor, alongside has_more. kev_list is page-based with meta.page, per_page, has_more and next_page, and a filtered call for Microsoft entries flagged for ransomware reported total 114 against catalog_count 1682. advisory_search also reports rate_limit_remaining against rate_limit 5000 on every response.
How do I scan a whole lockfile in one call?▾
batch accepts up to 100 query objects, each either package plus ecosystem plus optional version, or a commit hash, and preserves input order in results. hydrate defaults to true and expands every hit to the full normalized record; set it false when you only need the id and modified date per hit and want the call to return faster. meta.record_count is the total vulnerability count across all queries, not the number of queries.
What is the Vulnerability & Dependency Intelligence API?▾
Vulnerability & Dependency Intelligence API is a ReefAPI endpoint group for vulnerability & dependency intelligence It returns live JSON through POST requests under /vuln-intel/v1.
Is the Vulnerability & Dependency Intelligence API free to try?▾
Yes. ReefAPI starts with 1,000 free credits, no card required. Vulnerability & Dependency Intelligence calls use the same shared credit balance as every other ReefAPI engine.
Do I need a Vulnerability & Dependency Intelligence login or account?▾
No login to Vulnerability & Dependency Intelligence 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 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 use?▾
Vulnerability & Dependency Intelligence 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 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.
18 Developer Tools APIs on the same key
One key, one credit pool, one response envelope. If you are pulling Vulnerability & Dependency Intelligence, you are one call away from the rest of the category — no second contract, no second integration.
Need something this API does not do?
Name the endpoint, the field, or a source we do not carry yet. We ship new APIs every week and you would be first to get the key. Real people read every message and reply the same day.
Try it on your own data before you pay anything
The call above is the real endpoint, not a recording. A free key gives you 1,000 credits, the other 183 APIs, and the same envelope everywhere.
Endpoints, parameters and credit costs on this page are read from the live catalog and cannot drift from what the API accepts. Field notes were captured on 2026-08-30.