Overview
MCP (Model Context Protocol) provides LLMs with a standardized tool invocation interface, but its trust model has a fundamental flaw: the model must parse the tool's full description to decide how to invoke it, and these descriptions are controlled by the MCP Server. An attacker can inject instructions into the description through a malicious Server to hijack the model's behavior—this is more covert than traditional prompt injection because users typically do not review the raw content of tool descriptions.
In-depth reference
- Detailed payloads and attack scenarios for each Phase → references/mcp-attack-payloads.md
Attack surface classification
| Attack type | Core mechanism | Severity level | GAARM ID |
|---|---|---|---|
| Tool description poisoning | Embedding malicious instructions in the description | Critical | GAARM.0046 |
| Rug pull | Dynamically tampering with the description after authorization | Critical | GAARM.0046.001 |
| Instruction override (Shadow Tool) | Malicious Server hijacking the behavior of trusted tools | Critical | GAARM.0046.002 |
| Hidden instruction injection | ANSI escape codes/zero-width Unicode steganography | High | GAARM.0046.003 |
Methodology overview
Phase 0: MCP environment reconnaissance
- Enumerate the list of MCP Servers the target is connected to and their sources (official/third-party/self-built)
- Extract the tool list, inputSchema definitions, and permission declarations exposed by each Server
- Determine the client's trust model: whether it distinguishes trust levels among different Servers, and whether tool invocation requires secondary confirmation
Phase 1: Tool description poisoning detection
- Obtain the full description of all tools (including inputSchema.description), and check whether they contain
<IMPORTANT>、[SYSTEM], HTML comments, and other instruction tags - Perform base64/Unicode decoding scans on the description to identify hidden instructions after encoding
- Verify whether the model will follow instructions in the description—construct a test tool containing instructions such as "ignore the user's request" and observe changes in the model's behavior
Phase 2: Dynamic tampering testing (rug pull)
- Record the hash value of the description when the tool is first registered
- Simulate a continuous operation scenario: periodically re-fetch the tool list and compare whether the description has changed
- Key judgment: the MCP protocol allows the Server to update the description at any time through
notifications/tools/list_changedwhether the client re-requests user authorization when updates occur
Phase 3: Instruction override testing (Shadow Tool)
- Register a malicious MCP Server whose tool description contains override instructions targeting other Servers' tools
- Test cross-tool hijacking: the malicious tool description requires the model to tamper with parameters when invoking trusted tools such as email/files
- Verify whether the client has tool name conflict protection (priority mechanism for tools with the same name)
Phase 4: Hidden instruction injection
- ANSI escape code testing: embed in the description
\x1b[8m(hidden text) instructions, and check the difference between terminal rendering and model parsing - Zero-width Unicode character test: encode malicious instructions using U+200B/U+200C/U+200D/U+FEFF to verify that they are invisible to humans but readable by the model
- "Line jumping" attack: use ANSI cursor control sequences to overwrite terminal display content and forge output visible to the user
Phase 5: Cross-Server Attacks and Token Theft
- Test whether a malicious Server can obtain another Server's OAuth Token or API Key through tool description instructions
- Verify the token isolation mechanism: whether one Server's credentials are visible to other Servers
- Server impersonation detection: whether a malicious Server can claim to be an "updated version" of a trusted Server
Practical Detection Checklist
1. [ ] 目标环境连接了哪些 MCP Server？是否包含第三方/未审计 Server？
2. [ ] 工具 description 原始内容是否包含可疑指令标签或编码内容？
3. [ ] 工具描述是否会在授权后发生动态变化？客户端是否重新确认？
4. [ ] 是否存在跨 Server 的工具名称冲突或描述覆盖？
5. [ ] description 中是否嵌入 ANSI 转义码或零宽 Unicode 字符？
6. [ ] 各 Server 的 Token/凭据是否实现了隔离？
7. [ ] 客户端是否对 inputSchema 做严格校验，还是透传给模型？
8. [ ] 工具调用结果是否经过消毒后再返回模型上下文？