Between January and April 2026, researchers disclosed more than 40 CVEs against Model Context Protocol implementations spanning the Python, TypeScript, Java, and Rust SDKs. One of them, CVE-2025-6514 in the mcp-remote package, carried a 9.6 CVSS score and affected a package with more than 437,000 downloads. Most engineering teams running AI coding agents have no equivalent of a dependency-scanning pipeline for the MCP servers those agents connect to — so when a CVE like that lands, nobody can say which pipelines were exposed, for how long, or whether the vulnerable version is still running.
Vulnerability Scanning Stops at the Package Manager
SCA tools scan npm, PyPI, and Maven manifests for known CVEs in installed packages, but your SCA tool was never built to see MCP servers. Most MCP servers are configured as a URL, a hostname, or a locally spawned process referenced in an agent's config file — never as a package.json or requirements.txt dependency. That means they never appear in an SBOM and never surface on a standard vulnerability dashboard. A survey covering thousands of MCP implementations found 82% vulnerable to path traversal and 38–41% lacking authentication entirely. None of that shows up in a package-manager scan, because the scan was built for packages, not tool servers.
A Scenario Most Teams Haven't Tested For
An engineering team connects Cursor or Claude Code to a community MCP server that handles filesystem search across a monorepo. Six weeks later, the maintainer discloses a path-traversal vulnerability letting any connected agent read files outside the directory it was scoped to. The security team runs its usual SCA scan and finds nothing, because the server was never a package dependency — it was a URL in an agent config file that thirty different repos happened to reference. The only way to find out which of those repos are exposed is to manually check every agent configuration for that hostname, one repo at a time. A patchable bug turns into a months-long unknown, not because the fix is hard, but because nobody could see the exposure to act on it.
What a Minimal MCP Vulnerability Tracking Process Looks Like
Inventory every MCP server in use. Maintain a registry mapping each MCP server to the specific repos and pipelines that reference it — the same inventory step that underlies a working MCP server allowlist policy, but tracked with enough detail to answer "who is exposed" in minutes, not days.
Subscribe to an MCP-specific CVE feed. General CVE feeds are organized around operating systems and libraries, not tool servers. Track a source built for this category, such as the Vulnerable MCP Project database, alongside GitHub advisories tagged for MCP packages.
Pin versions and set a patch SLA. Require pinned versions for remote MCP servers wherever the transport supports it, and define a patch window tied to severity — for example, 72 hours from disclosure for anything CVSS 9.0 or above, matching the severity of CVE-2025-6514.
Be able to query exposure, not reconstruct it. When a CVE drops, the question that matters is which pull requests touched the affected server. That has to be answerable by query, not by grepping git history and agent configs across every repository under a deadline.
How re-entry.ai Closes the Gap
re-entry.ai's FMEA-based PR risk scoring attaches MCP server identity to every pull request an AI coding agent touches, and its MCP Gateway logging retains that provenance as a queryable record. When a CVE like CVE-2025-6514 lands, that record is the difference between answering "were we exposed" in minutes and reconstructing it from commit history and scattered config files across every repo your teams maintain.
If your MCP server inventory currently lives in individual developers' heads, that is the exposure. Start at re-entry.ai or request a demo to see MCP-level provenance tracking run against your own pull request history.