Use it from anywhere

https://vulns.fencer.dev/feed returns RSS. Add format=atom or format=json (JSON Feed 1.1) for the other formats. Each feed holds the 50 newest matching entries.

In Slack, /feed subscribe https://vulns.fencer.dev/feed?filter=critical posts each new entry to the channel (Slack's built-in RSS app). Any feed URL works, including the one on a stack report.

filter

critical or kev. An entry is critical when it is in CISA KEV, when CISA SSVC says exploitation is active, when it scores CVSS 9+ in a listed technology (a WordPress plugin or theme does not count, only WordPress itself), or when it scores CVSS 7+ with EPSS ≥ 0.1. A KEV-only feed is ordered by the date CISA added the entry.

tech

A technology slug from the list below.

ecosystem

npm, pypi, go, maven, crates.io, packagist, rubygems, hex, nuget, github-actions, pub, swift, hackage, ghc, cran, opam, julia, bitnami

vendor

A vendor or product name, matched as a substring of the CNA, CISA and NVD vendor and product names, e.g. vendor=fortinet or vendor=exchange server. One value, 2–60 characters.

Combining filters. filter, tech and ecosystem each take a comma list or repeat; vendor takes one value. An entry must match any value of a field, and every field you give. A feed allows at most 16 combinations (the product of the value counts).

Examples

• /feed Everything, newest first
• /feed?filter=critical Only critical entries
• /feed?filter=kev Added to CISA KEV, by date added
• /feed?filter=critical,kev Critical or KEV
• /feed?tech=nextjs,react Next.js or React
• /feed?filter=critical&tech=nextjs,react Critical, and Next.js or React
• /feed?ecosystem=npm&filter=critical&format=json Critical npm entries as JSON Feed
• /feed?tech=fortinet&filter=kev&format=atom Exploited Fortinet bugs as Atom

Every filter view on the front page shows its own feed URL. For your dependencies, use Check your stack.

Every endpoint sends Access-Control-Allow-Origin: *. Errors come back as {"error": "…"} with a 4xx status, or 500 on an internal error.

GET /api/v1/entries/<id>

One entry. Aliases redirect (302) to the canonical id, so follow redirects.

GET /api/v1/entries

filter, tech, ecosystem and vendor as for feeds, plus limit (1–200) and cursor. Newest first; pass next_cursor back as cursor.

GET /api/v1/search

q, severity, kev, exploited, tech, ecosystem, vendor, package, published, type (cve|ghsa|osv), limit, offset (up to 1000). q is at most 200 characters. Results carry matched reasons and facet counts; when nothing matches, broader suggests looser queries. published takes 2024, 2024-05, 2024-01-01..2024-03-31, >=2024-01-01, <2024-01-01 or 30d. exploited means in CISA KEV or with an Exploit-DB or Metasploit exploit.

POST /api/v1/stack

JSON {"filename": "package-lock.json", "content": "…"} or {"packages": "npm:lodash@4.17.20,pypi:django@4.2.0"}, or a multipart upload in a lockfile field (lockfiles 5 MB, SBOMs 10 MB, 5,000 packages max). packages may also be an array of {ecosystem, name, version}. Returns findings, eol (versions out of support), other, unchecked, packageCount and checked, flattened, plus id, url and feed. GitHub Actions workflows work as lockfiles: each uses: owner/repo@ref is matched against the advisory ranges, a floating tag (v4) as the newest release of its line. Actions pinned to a commit SHA (without a # v1.2.3 comment) or a branch can't be compared and come back in unchecked, with the advisories on file for them. An SBOM (CycloneDX JSON, SPDX 2 JSON or Syft JSON, e.g. syft <image> -o cyclonedx-json, or Trivy's CycloneDX or SPDX) works in lockfile or content, as text or, for a large one, as the SBOM's JSON object itself: its language packages are checked as above, its deb, apk, rpm and Arch (alpm) packages against the distro advisories for their release, returned in os (releases, each with unchecked set to distro, release, version (the SBOM gives no release) or derivative (with basedOn: Manjaro, EndeavourOS and other Arch-based distros; only Arch Linux itself is checked) where they can't be checked; findings with the fixed version and advisories per package, and possible: true on a finding or package line from Arch Linux, whose tracker gives a fix but no introduced version, so the package may predate the bug (such findings are not counted as known exploited or critical); other; and licenses, the CC BY-SA terms that travel with Ubuntu and Alpine data).

GET /api/v1/stack/<id>

A stored report: {id, name, created, packages, osPackages, result}, with the POST fields under result. It is re-checked when older than 6 hours. Reports nobody opens (page, API or feed) for 90 days are deleted.

GET /stack/<id>/feed

RSS (or format=atom|json) of a stored report's findings: the feed URL that POST returns.

GET /stack?p=…

RSS (or format=atom|json) of entries affecting exactly those versions. Nothing is stored.

GET /api/v1/status

Source sync health and catalog counts.

curl -sL https://vulns.fencer.dev/api/v1/entries/CVE-2021-44228
curl -s 'https://vulns.fencer.dev/api/v1/search?q=log4j&kev=1'
curl -s -F lockfile=@package-lock.json https://vulns.fencer.dev/api/v1/stack

Lockfiles: package-lock.json, bun.lock, pnpm-lock.yaml, yarn.lock, requirements.txt, poetry.lock, uv.lock, Pipfile.lock, Cargo.lock, go.sum, Gemfile.lock, composer.lock, mix.lock, packages.lock.json, gradle.lockfile, .github/workflows/*.yml, action.yml, pubspec.lock, Package.resolved, renv.lock, Manifest.toml, cabal.project.freeze, *.opam.locked.

Streamable HTTP, stateless, no authentication. Add it to your agent with one line:

claude mcp add --transport http fencer-vulns https://vulns.fencer.dev/mcp

codex mcp add fencer-vulns --url https://vulns.fencer.dev/mcp

{
  "mcpServers": {
    "fencer-vulns": {
      "url": "https://vulns.fencer.dev/mcp"
    }
  }
}

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "fencer-vulns": {
      "type": "remote",
      "url": "https://vulns.fencer.dev/mcp",
      "enabled": true
    }
  }
}

Tools

search

Search Fencer Vulns entries (CVE, GHSA and OSV advisories merged into one entry per vulnerability). Free text in `q` matches ids, titles, descriptions, vendors, products and package names; structured parameters narrow the result. Each result says why it matched; when nothing matches, `broader` lists relaxed queries that do return results.

get_vulnerability

Full entry for a CVE, GHSA or OSV id: description, CVSS, CISA KEV status and due date, EPSS score and the date it first reached 10%, public exploits (Exploit-DB, Metasploit) and Nuclei checks, affected packages with fixed versions, affected products, references and source records; where known, ATT&CK techniques (attack), ransomware groups (ransomware) and the Project Zero zero-day listing (zeroDay); vendorAdvisories holds vendor CSAF advisories and VEX statements (CISA, Red Hat): per product affected, fixed or not affected, with the remediation and a link (keep the credit of each with it); maintainerAdvisory links the advisory the maintainers published on their GitHub repository and says whether the entry is unreviewed (nothing but that advisory).

list_feed

Newest entries of a feed, the same as the /feed endpoint. `filter`: critical = in CISA KEV, or CISA SSVC exploitation "active", or CVSS 9+ in a listed technology (WordPress plugins and themes excepted; WordPress itself counts), or CVSS 7+ with EPSS ≥ 0.1; kev = in CISA KEV (ordered by date added). An entry must match any value of a field and every field given.

check_stack

Check exact package versions for known vulnerabilities. Pass a lockfile's contents (package-lock.json, bun.lock, pnpm-lock.yaml, yarn.lock, requirements.txt, poetry.lock, uv.lock, Pipfile.lock, Cargo.lock, go.sum, Gemfile.lock, composer.lock, mix.lock, packages.lock.json, gradle.lockfile, .github/workflows/*.yml, action.yml, pubspec.lock, Package.resolved, renv.lock, Manifest.toml, cabal.project.freeze, *.opam.locked) with its filename, an SBOM (CycloneDX JSON, SPDX 2 JSON, Syft JSON, e.g. from `syft <image> -o cyclonedx-json`; up to 10 MB) in the same field, or a package list. An SBOM's language packages are checked like a lockfile's; its OS packages (deb, apk, rpm and Arch alpm purls) are matched against the distro advisories for their release and come back in "os" (findings with the fixed version per package; releases with no advisories on file are marked unchecked, never guessed, and Arch-based distros such as Manjaro as unchecked "derivative"; a finding or package with possible: true comes from Arch's tracker, which gives no introduced version, so the version may predate the bug: say "may be affected"; keep the license objects of share-alike distro data with it). A GitHub Actions workflow or action.yml works too: each uses: owner/repo@ref is checked, a floating tag (v4) as the newest release of its line; refs pinned to a commit SHA (without a "# v1.2.3" comment) or a branch come back in "unchecked" with the advisories on file. Also lists versions endoflife.date marks as out of support (eol). No matches means none were found, not that the packages are safe.

Paste this into your project's AGENTS.md or CLAUDE.md so your agent checks dependencies before it adds them. The same facts, in plain text, are at /llms.txt.

## Dependencies and vulnerabilities

Use the Fencer Vulns MCP server (https://vulns.fencer.dev/mcp, no auth) or https://vulns.fencer.dev/llms.txt.

- Before adding or upgrading a dependency, call check_stack with the lockfile contents (or packages at exact versions).
- For any CVE, GHSA or OSV id, call get_vulnerability: it says whether the entry is in CISA KEV, its EPSS score and when it first reached 10%, public exploits and fixed versions.
- No matches means Fencer Vulns found none, not that the packages are safe.

1. 01 One entry per vulnerability. Records that name each other as aliases are merged.
2. 02 The entry id is the CVE id when there is one, then the GHSA id, then the record's own id (PYSEC-, GO-, RUSTSEC-…).
3. 03 Two different CVEs never merge, even when an advisory lists both.
4. 04 Every other id redirects to its entry: /GHSA-… leads to the CVE it belongs to.
5. 05 KEV, EPSS, EUVD and exploits (Exploit-DB, Metasploit, Nuclei) attach by CVE id; /EUVD-… redirects to its CVE entry.
6. 06 Distro advisories (Debian, Ubuntu, Red Hat, SUSE, openSUSE, AlmaLinux, Rocky Linux, Alpine, Azure Linux, Arch Linux) attach by the CVEs they fix and show as distro packages under Patch / fix. They are not entries of their own. Ubuntu and Alpine fixes are CC BY-SA 4.0 and Azure Linux fixes MIT: in the API their fixes.distros block carries a license object (name, url, attribution) to pass on with them.
7. 07 Vendor CSAF advisories (CISA ICS and IT advisories, Red Hat VEX) attach by CVE as vendorAdvisories and show under Vendor advisories: per product affected, fixed or not affected, the remediation (vendor fix with the fixed version, workaround, mitigation, no fix available, no fix planned) and a link. They do not change critical. CISA's republications of vendor advisories are kept as facts and a link only; each advisory carries a credit object (name, url, attribution) to pass on with it.
8. 08 GitHub repository advisories: for the repositories behind the tracked technologies (Next.js, React, Rails, PHP, Redis, WordPress and others), the maintainers' own advisories on GitHub are read too, including ones GitHub never reviews into its Advisory Database. They merge by GHSA id (and CVE, when they name one) and rank below every reviewed source: scores, packages and weaknesses come from them only where no reviewed record has that field. An entry with nothing else is labelled unreviewed: maintainerAdvisory.unreviewed in the API and MCP, unreviewed in lists, _fencer.unreviewed and the item text in feeds. They are the maintainers' content under GitHub's terms, so only facts, the headline and a link to the advisory are kept, never its description.
9. 09 Where Anchore has corrected NVD's CPE configuration (anchore/nvd-data-overrides), the correction replaces NVD's CPEs and fixed versions.
10. 10 Only Exploit-DB and Metasploit count as public exploits (exploitCount in API lists and search, exploit_count in MCP results); the search filter exploited=1 means in CISA KEV or with such an exploit; Nuclei templates are detection checks.
11. 11 ATT&CK techniques (attack, from MITRE CTID's KEV mappings), ransomware groups (ransomware, from BushidoUK's Ransomware Vulnerability Matrix, CC BY 4.0) and Project Zero's zero-day listing (zeroDay: dates and a link) attach by CVE id. attack and ransomware carry a credit object (name, url, attribution) to pass on with them. None of them changes critical.
12. 12 Lockfile reports flag unsupported versions (eol) from endoflife.date, only where endoflife.date names the package itself and the version falls in one of its release cycles.

An entry is filed under a technology through its CPEs, its CNA vendor and product strings, or its affected packages. WordPress plugins and themes also match by the CNA that assigned the CVE (WPScan, Wordfence, Patchstack), by advisory pages on wpscan.com, wordfence.com and patchstack.com or WordPress.org plugin and theme links, and by CPEs that target WordPress. Those plugin and theme matches file the entry under tech=wordpress but do not count as a listed technology for filter=critical: there are thousands of plugins, most with few installs. The matchers are deliberately narrow.

• Next.js nextjs rss / critical
• React react rss / critical
• Node.js node rss / critical
• Express express rss / critical
• Django django rss / critical
• Flask flask rss / critical
• Ruby on Rails rails rss / critical
• Spring spring rss / critical
• Log4j log4j rss / critical
• Kubernetes kubernetes rss / critical
• Docker docker rss / critical
• nginx nginx rss / critical
• Apache HTTP Server apache-httpd rss / critical
• OpenSSL openssl rss / critical
• PostgreSQL postgresql rss / critical
• MySQL mysql rss / critical
• Redis redis rss / critical
• Microsoft SQL Server microsoft-sql-server rss / critical
• Oracle Database oracle-database rss / critical
• MariaDB mariadb rss / critical
• IBM Db2 ibm-db2 rss / critical
• MongoDB mongodb rss / critical
• SAP ASE sap-ase rss / critical
• PHP php rss / critical
• WordPress wordpress rss / critical
• Jenkins jenkins rss / critical
• GitLab gitlab rss / critical
• Fortinet fortinet rss / critical
• Citrix citrix rss / critical
• Ivanti ivanti rss / critical
• Cisco IOS cisco-ios rss / critical
• Palo Alto PAN-OS palo-alto-panos rss / critical
• VMware vmware rss / critical
• Microsoft Exchange microsoft-exchange rss / critical
• Google Chrome chrome rss / critical
• Linux kernel linux-kernel rss / critical