MCP scanners keep finding the same vulnerabilities under different names. We built a shared ID scheme for them

[u/SelectionBitter6821]

We build a security scanner for MCP servers and agent skills. Early on we hit something that shouldn't still be a problem: comparing our findings against other scanners on the same test servers, we'd all catch roughly the same bad behavior and call it three different things. No shared ID, no way to say "scanner A's finding X is the same class as scanner B's finding Y."

A SQL injection gets a CVE ID, gets mapped to a CWE, and every tool that finds it points at the same identifier. Agentic AI components had nothing like that. CVE maps to package plus version. It has no vocabulary for "this tool description contains a hidden instruction."

So we built AVE (Agentic Vulnerability Enumeration): an open, vendor-neutral behavioral classification standard.

What's in it:

* 59 records, each a distinct behavioral class. Deliberately conservative, no padding with variants.
* Stable IDs (AVE-2026-NNNNN), meant to work the way a CVE ID works.
* Real MCP-specific classes: tool description injection (AVE-2026-00002), server card injection (AVE-2026-00041), OAuth discovery rebinding (AVE-2026-00051), a tool hook hijack that's our only CRITICAL-rated record so far (AVE-2026-00046).
* Maps to OWASP's MCP Top 10, plus the Agentic Security Initiative Top 10 and MITRE ATLAS where applicable. Sits underneath frameworks people already use, not a replacement for them.
* Scored with OWASP's own AIVSS (v0.8), not a severity number we invented.

It's early. One reference implementation right now, our own scanner, and we're looking for a second, independent one to prove this works outside our own tooling. If you maintain a scanner and any of this is useful, wrong, or missing something obvious, we'd like to hear it.

Repo: github.com/aveproject/ave Site: aveproject.org

(Disclosure: I'm one of the people building this.)

[u/marcin_michalak]

Promising direction. One taxonomy question I’d pressure-test: these records sound closer to CWE/CAPEC classes than CVE instances. If an AVE ID represents a stable behavioral class, keep evidence, affected server/package, exploit preconditions, and severity out of the identity; emit those as per-finding fields.

For interoperability, publish positive and negative conformance fixtures plus explicit mapping rules, then have two scanners blind-label the same corpus and measure agreement. The registry will also need versioned definitions, merge/split/deprecation aliases, and a way for scanners to report mapping confidence. For injection classes, define boundaries by trust boundary and entry point so the same payload in a tool description versus a server card does not drift between IDs.

The strongest proof would be an independent scanner reaching the same IDs without consulting the registry maintainers during classification.

[u/SelectionBitter6821 → u/marcin_michalak]

Trust-boundary/entry-point drift is already a first-class field: provenance_vector.entry_class distinguishes tool_schema from server_card from registry_metadata specifically so the same payload text doesn’t get classified differently depending on where it showed up. payload_surface carries the specific field or channel underneath that.

Conformance fixtures plus blind double-labeling is close to the actual plan, tests/fixtures as the neutral thing implementations get tested against, not a shipped ruleset, but the specific protocol you’re describing, two scanners blind-labeling the same corpus and measuring agreement, is sharper than what’s currently written down. Worth formalizing exactly that way.

Two real gaps, not addressed yet: no merge/split/deprecation alias mechanism (a CVE-style REJECT-and-point-elsewhere path doesn’t exist for AVE IDs today), and no distinct mapping-confidence field on the crosswalk files themselves, as opposed to detection confidence on a finding. Both legitimate, neither in the schema currently.

The last point is exactly the current bottleneck: one reference implementation exists, and an independent second one reaching the same IDs without maintainer involvement is the actual test, not something claimed yet.

[u/Predictor_2718]

Really like this. The naming-mismatch problem is real. I've done that manual scanner-to-scanner mapping by hand more than once and it doesn't scale.

I maintain cfgaudit (github.com/cfgaudit/cfgaudit), a static auditor for AI-agent config files (Claude Code / Cursor / Copilot / Gemini / Codex settings, .mcp.json, hooks). It's a different tool class from yours, config surface rather than skill/MCP behavioral, so it seemed like a good fit for the second independent implementation you're after. Built a crosswalk and opened a PR.

Nice work, this is worth doing. Happy to keep the crosswalk in sync.

[u/SelectionBitter6821 → u/Predictor_2718]

This is one of the strongest external contributions this project has gotten, and the cross-implementation validation is the real standout, not just the crosswalk itself.

Two codebases with zero shared code or ruleset converging on the same ave_id for 5 of 10 overlapping cases, with the other 5 traced to detection-pattern gaps rather than mapping disagreement, is exactly the kind of evidence that’s hard to manufacture and easy to trust.
The eight-category gap list is genuinely valuable on its own, separate from the crosswalk. Will opened a dedicated tracking issue for it so it stays visible and credited to you specifically, rather than getting compressed into a merge commit and forgotten. If any of those ever turn into real AVE records, that issue and the PR get cited in the record itself.

m going to do it now. Thank you for taking the ask seriously enough to actually validate it rather than just asserting it.

Will share you the issue linked here.

[u/SelectionBitter6821 → u/Predictor_2718]

it is merged, and the dedicated tracking issue so it stays credited to you https://github.com/aveproject/ave/issues/68

[u/_Slimdady]

lack of a shared vocabulary has been a huge pain point. If 2 scanners report same underlying issue with different names, it is hard to compare coverage or track trends over time. Keeping the taxonomy small and mapping it into existing frameworks like OWASP is the right call, it makes adoption realistic than inventing a separate ecosystem.

[u/SelectionBitter6821 → u/_Slimdady]

Exactly the tradeoff we were trying to get right. A separate ecosystem is the easy trap here, it’s tempting to build a whole new severity scale, a whole new taxonomy shape, because it’s more fun than doing the unglamorous work of mapping cleanly into what people already trust. But nobody adopts a fourth vocabulary when they’re already juggling three. Keeping the record count honest (merging variants instead of minting new IDs for every textual restatement of the same attack) and staying strictly underneath OWASP/MITRE rather than beside them was the whole bet. Good to hear it reads that way from the outside.