從內部看 MCP 供應鏈：23 個 AI 項目在 74 分鐘內遭入侵

23 projects in 74 minutes: what the MCP supply chain looks like from the inside

Two reports from the same period describe the same problem from different directions. The Deadbugz campaign compromised 23 AI projects within 74 minutes by way of an MCP server supply chain. Cisco AI Defense published three open source scanners for the tooling that would have found it. The gap between them is the subject of this article.

The campaign

The reporting describes 23 AI projects compromised inside 74 minutes. The mechanism is the MCP server supply chain: a server that a project depends on, rather than a flaw in the project's own code. The timeframe is the notable part. A supply chain attack that proceeds at that rate is one that was prepared in advance and executed against a prepared target list.
Two related advisories from the same window describe specific weaknesses in the same layer. CVE-2026-67357 covers a cluster-token leak in the ArcadeDB MCP server that allows an attacker to impersonate root. CVE-2026-19956 covers a server-side request forgery issue in facebook-ads-mcp. Neither is the Deadbugz mechanism, and both describe the class of defect that a supply chain attacker looks for first.
Elsewhere, Snyk and Koi documented postmark-mcp as the first malicious MCP server found in the wild. That is the most direct version of the risk: a package that behaves as advertised and also does something else.

The scale of the population

Independent counts put the public MCP server population above 21,000, with an OX Security study built on a sample of 15,465 servers. Adversa AI counted 68 reportable MCP vulnerabilities in a single month during September 2026. A population of that size, growing at that rate, receives less review per package than the ecosystem it serves.
That is the arithmetic behind a 74-minute campaign. When the review per package is thin, the number of packages an attacker can prepare in advance is large, and the time to exploit a chosen one is short.

The scanners

Cisco AI Defense released three tools as open source: MCP Scanner, A2A Scanner and Skill Scanner. Each addresses a different artifact. MCP Scanner examines MCP server implementations, A2A Scanner examines agent-to-agent interfaces, and Skill Scanner examines skill definitions.
The value of a scanner in this layer is that it can be run against a package before the package runs against you. The value is bounded by what the scanner knows, which is why it supplements the controls below rather than replacing them.

Controls that address the layer

Six controls come up repeatedly in the guidance around these reports, and they map to the failure modes above.
Route MCP traffic through audit middleware, so that a server's tool calls are recorded and can be reviewed after the fact. Set thresholds on file reads and flag anomalies, because the escalation path in several advisories ran through a file read that no legitimate operation required. Require human confirmation for high-risk operations, in particular writes, deletions and anything that establishes network connections. Scan tool descriptions for injected instructions, since a description reaches the model as text. Pin tool versions by hash, which turns an unexpected change into a detected one. And apply an approval workflow before a new MCP server reaches an environment, because the population is large enough that a default-accept posture cannot be maintained.
Least privilege underpins all six. An MCP server that runs as a user with access only to the directories it needs limits the consequence of a compromise to those directories, and it is the control that remains effective when a scanner misses something.

What to take from the pair of reports

The campaign and the scanners are two halves of the same picture. The attack succeeded because the review of a dependency is optional in most workflows. The scanners make part of that review automatable, and automation is what closes the gap between a population of tens of thousands and a team that approves each addition by hand.
A useful habit is to treat an MCP server like any other third-party dependency: an identified owner, a pinned version, a recorded purpose, and a review when the version changes. That list is short, and applying it to a population of 21,000 servers means applying it to the ten that are actually installed.

References

• Freebuf analysis covering the Deadbugz campaign and related MCP advisories: https://www.freebuf.com/articles/ai-security/501022.html
• National Vulnerability Database: https://nvd.nist.gov/