State of MCP Package Security

Where the ecosystem stands

The headline is that most published MCP packages score well. Out of 1,000 scored packages, mean score is 92.2 of 100 and the median is 95. Risk categorisation is dominated by LOW (903 packages, 90%), with a long tail of packages at ELEVATED or worse that represents the material supply-chain surface a consumer actually has to worry about.

Interpretation: the concentration at 90-100 reflects the MCP ecosystem's current publisher skew. Most packages are small, recent, and do not bundle risky behaviours. The packages below 70 are what the Policy Gate is designed to catch before they land in a repo.

What the scanner finds most

Across the most recent 500 scans, the scanner produced 576 findings total (76% of scans returned at least one finding). The most common finding is the absence of provenance attestations, a verifiability gap rather than a vulnerability. The tail is where real security issues concentrate.

Capability surface across the ecosystem

Capability classification runs across MCP tool definitions extracted from each package's source. These are the powers a consuming agent inherits when it installs a package. 587 monitored packages have classified capability surfaces on file. The counts below are packages with that capability present (a single package can declare many).

The distribution is instructive for consumers: a majority of classified packages declare either search, database, network, or email capabilities, which means installing an arbitrary MCP server by default grants at least one of those powers to any agent using it. The Policy Gate surfaces capability additions between versions so a consumer can decide whether a v1.4 → v1.5 bump that adds email_messaging was intended.

Install-script prevalence

Of 844 recently scanned packages, 58 (7%) publish at least one install-time script (preinstall, postinstall, or install). Most are benign (version banners, setup scripts), but the pattern is a classic supply-chain vector: any code in those scripts executes on npm install before the consumer has a chance to inspect the package. For MCP consumers who run agents in production, install-script packages deserve a manual review step.

Advisory cadence

AgentScore publishes public advisories when a monitored package materially worsens (score drop, new high-severity finding, new capability addition that changes the trust envelope). A total of 40 advisories have been published to date: 27 high-severity and 12 low-severity. Recent publications:

Machine-readable advisory feed: /security/advisories (HTML) and /security/advisories/rss.xml (RSS).

Case studies from this period

Numbers describe the ecosystem's shape. Cases describe how it actually responds when a finding lands in front of a maintainer. Three from the reporting period:

Maintainer response patterns

Of every disclosure or capability-change report we have filed since launch, four distinct positive-response shapes have emerged on the public record. Each is a different kind of proof point about what disclosure actually buys you in this ecosystem. Verified by re-reading the GitHub threads, commit dates, and npm release timelines on May 9, 2026.

The shapes are not interchangeable. Pinning is consumer-side defence. Author-side fixes are remediation. Technical pushback improves both sides. Corrected false-positives demonstrate the iteration loop. Treating any single response as “winning” misframes what each one actually proves. The fifth shape is the one we file most often: no response. The fa-mcp-sdk package has republished seven times since the original disclosure with no maintainer acknowledgement; cases like that route to the GitHub Security Lab CVE pipeline instead.

What this means for MCP consumers

• Pin your MCP dependencies. npx -y and unpinned npm specs pull whatever is latest at install time. Any maintainer compromise propagates without warning. This is the Redis lesson.
• Re-evaluate capability changes at bumps. A v1.4 to v1.5 patch that adds email_messaging, filesystem_write, or shell_exec is a scope change, not a routine update. The Policy Gate surfaces these automatically.
• Treat install scripts as a manual-review gate. 7% of packages in this sample publish one. Most are benign. The Policy Gate flags their presence so a human decides.
• Watch the advisory feed. Score drops and finding additions on packages already in your inventory are the early-warning signal. RSS: /security/advisories/rss.xml.