Your AI Skill Might Have a Known CVE. Nobody Was Checking.

By Michael Browne · April 23, 2026 · 6 min read

Every AI skill is a package in a trench coat. The MCP server sitting behind your agent is almost always an npm module, a Python wheel, or a Go binary. If the published version of that package has an unpatched critical in the public vulnerability databases, the skill carries that CVE into every workflow that installs it.

You wouldn't ship a production API that depends on a package with a CVE on the CISA Known Exploited Vulnerabilities catalog. But thousands of developers install AI skills every week with no equivalent check running at all.

What Existing AI Skill Scanners Check — And What They Miss

The npm and Python ecosystems have had mature vulnerability tooling for years. Dependabot, Snyk, osv-scanner, and GitHub's own advisory pipeline all cross-reference installed packages against CVE data as a matter of course. That work is solved for normal application dependencies.

The AI skill security tools are different. They grew out of prompt-injection research — the ClawHavoc and ToxicSkills papers — and anchored on a different threat model: malicious tool descriptions, credential access in code, shell execution, obfuscated payloads, tainted GitHub Actions workflows. Good signals. Necessary signals. Not sufficient.

What they consistently miss: the skill's own published version has a known CVE. The two disciplines matured in separate lanes, and almost no one was stitching them together. Our own scanner didn't do it either — until last week.

What v3 of Our Algorithm Changes

We shipped a new signal called known_vulnerabilities. For every skill we score, the engine resolves the primary installable package (walking the repo's workspace structure if it's a monorepo), then queries three public data sources against the latest published version:

• OSV.dev — the unified advisory database. One query returns every advisory from GHSA, npm, PyPA, Go, and RustSec that affects that specific version. Version-range math happens server-side, so nothing gets missed.
• CISA Known Exploited Vulnerabilities — the catalog of CVEs being actively exploited in the wild. KEV listing is an exploitation signal, not a severity signal. We still treat any KEV match as critical-priority in scoring, because active exploitation matters more than theoretical CVSS.
• FIRST.org EPSS — the Exploit Prediction Scoring System, which estimates the probability that exploitation activity is observed in the wild over the next 30 days. Anything above 0.7 (roughly the 99th percentile) caps the signal at 1/10; above 0.3 caps it at 3/10.

The signal is weighted into the Solid dimension (skills-mode = 0.06, partial = 0.10). But the more important change is the disqualifier.

If the latest published version has an unpatched critical, or if any CVE on the package is on the CISA KEV catalog, the skill is hard-gated to the Blocked tier. No composite score can offset it. No good behavior elsewhere earns the skill back. The version with the vuln either ships with a fix or it doesn't — and until it does, the skill can't be "Verified."

What the Corpus Shows

We just finished running a backfill across the OpenClaw and GitHub mcp-server ecosystems. Here's where the corpus sits as of this morning:

Fifteen skills in the Blocked tier is a small number in absolute terms — about 3.5% of the corpus. The composite scores of those blocked skills range from 4.9 to 6.1, meaning several of them would have landed in the Established tier without a disqualifier firing. A developer scanning them a month ago would have seen a mid-range number and moved on.

A skill ends up in Blocked for one of several reasons: a safety scanner hit in the tool definitions, a supply-chain risk in the CI pipeline, a missing or unclear license, an archived repo, a single-author skill with near-zero adoption, or — new in v3 — an unpatched critical CVE or a KEV-listed CVE in the published package. Before v3, CVE data wasn't part of the decision at all. Now it is.

We're working on surfacing the specific disqualifier in the public dataset so readers can see the breakdown themselves. For now, the defensible claim is narrower: a class of risk that previously sat in the blind spot of every AI-skill scanner we know of is now being acted on.

Why This Matters Right Now

The MCP ecosystem is expanding faster than anyone is governing it. The official MCP Registry lists 30 servers. Smithery, OpenClaw, mcp.run, and the npm long tail push the real number well past 17,000 — most of which have never been reviewed by anyone but the person who published them.

At the same time, CISA's KEV catalog is no longer just an enterprise-infrastructure concern. Over the past year it's added CVEs with npm and PyPI delivery vectors alongside the Windows and Cisco entries. Supply-chain attacks through package registries are first-class threats now. The question isn't whether an agent's skill stack contains a KEV-listed CVE — it's whether anything in the installation path is checking.

The uplift for AI skills specifically is worth stating plainly. An MCP server doesn't run like a normal npm dependency on some isolated backend; it runs inside the agent's context, often with broad credentials in environment variables, production API keys, and direct access to whatever the agent can reach. A CVE that leaks environment variables is materially scarier in a skill than in a standard library. The blast radius is different. The vetting should be too.

When you paste a skill into our scanner, that check happens automatically. When your agent calls our MCP server's auto_gate tool before installing, a blocked skill returns { proceed: false } with the CVE reason attached. When you hit the API directly, the response includes flags: ["CRITICAL_CVE"] for blocked skills. Same data, three surfaces.

What This Check Doesn't Cover

It's worth being explicit about the current scope, because the headline claim is narrower than the framing might suggest:

• Primary package only. We check the skill's own published package. Transitive dependencies aren't walked yet. Most serious supply-chain attacks come through transitives, so this is a real gap we're actively closing.
• Latest published version. We score what the maintainer currently publishes. If you're pinned to an older version, your actual exposure may differ from what we flag.
• Presence, not reachability. A CVE in a code path the skill never calls still counts. We don't do reachability analysis. That's intentional — reachability for dynamic languages is expensive and error-prone — but it means some flags are more conservative than the actual risk.
• Known CVEs only. Zero-days, unreported vulnerabilities, typosquats, dependency confusion, and starjacking are separate threat classes. The other signals in the algorithm cover some of that; CVE data by itself doesn't.

What's Next

Two things we're working on that build on this foundation:

1. Per-CVE detail in full reports — today the paid report shows you that a CVE was found; next we're surfacing the advisory ID, severity, and patched version so maintainers can see exactly what needs bumping.
2. Transitive dependency CVE coverage — the next pass walks the lockfile to catch CVEs in the transitive tree.

If you're shipping AI skills yourself, the fastest way to stay out of the Blocked tier is to run osv-scanner (or equivalent) in your release pipeline and bump before publishing when anything critical lands. It's the same data we query, so if it's clean there it'll be clean here.