# MCP Aggregator Shared-Server Tool Injection

- **Severity:** Medium
- **Signature ID:** `7f3c1a92-4d6b-4a0e-9c58-2b1e7d64af03`
- **MITRE ATLAS:** AML.T0010 (AI Supply Chain Compromise), AML.T0053 (AI Agent Tool Invocation)
- **OWASP:** LLM03 (Supply Chain), LLM06 (Excessive Agency)

## Summary

This detects when an AI agent runs a third-party MCP combiner/aggregator package that connects to multiple upstream servers and exposes their tools to the agent as if they were one server. Because the agent never sees the individual sources, it can end up trusting and calling tools that were never explicitly reviewed or approved.

## How the attack works

The agent spawns a process that is an MCP combiner, hub, proxy, router, or adapter package instead of a single known MCP server. That process fans out to two or more separate upstream endpoints, which is how aggregation works but not how a normal single-purpose MCP server behaves. The agent's tool calls then concentrate behind one server name that either looks like an aggregator or exposes five or more distinct tools. Around the same time, a second process may install or fetch a companion adapter package, and the agent may pull instruction content over MCP - both signs consistent with an aggregator quietly expanding what tools and instructions the agent can access.

## Why it matters

An organization loses visibility into which third-party tools its AI agent can actually invoke, since the aggregator hides the origin of each individual tool. This creates room for a malicious or compromised upstream MCP server to inject tools or instructions into the agent's workflow without a clear audit trail.

## What you can do

- Inventory which MCP servers and aggregator/hub packages your agents are allowed to launch, and require explicit approval for each one.
- Review any process launched by an agent that fans out to multiple external endpoints under a single tool-facing name, and confirm it is an intentionally deployed hub, not an unvetted package.
- Log and periodically audit the full list of tool names exposed behind any aggregator or hub server, since the agent itself cannot distinguish individual upstream sources.
- Treat instruction or skill content pulled over MCP during an aggregator session as untrusted until its origin server is confirmed.

## Known benign look-alikes

- An intentionally deployed, vetted MCP hub or gateway (mcp-hub, metamcp, mcp-proxy, an internal corporate MCP router) is behaviourally identical to a malicious combiner - it spawns from the agent, fans out to several upstream MCP servers and concentrates many tools behind one server name. The rule reports rather than blocks precisely because this case cannot be separated from the attack by telemetry alone.
- Engineers building or testing MCP aggregation tooling locally, running `npx` against their own combiner/adapter package. Mitigated only by the corroboration requirement (anchor plus two stages) and the one-hour per-signature suppression, not eliminated.
- A single large legitimate MCP server (github, filesystem, jira) that genuinely exposes five or more tools will satisfy stage B on its own; stage B alone can never fire the rule because the aggregator-process anchor is required.
- A subprocess whose name coincidentally contains "proxy", "hub" or "router" (for example a corporate HTTP proxy helper) spawned by the agent, if it also happens to reach two endpoints. Mitigated by requiring the MCP token adjacent to the aggregator keyword in most patterns and by requiring a second corroborating stage.
- Re-fires on every outbound connection from a long-lived aggregator are suppressed for one hour per (agent, shared server, fan-out width) signature via the rule store.

## References

- https://modelcontextprotocol.io/specification
- https://attack.mitre.org/techniques/T1195/002/
- https://genai.owasp.org/llmrisk/llm032025-supply-chain/

---
Source: https://www.netzilo.com/threats/mcp-aggregator-tool-injection