WhatsApp MCP tool poisoning attack
Invariant Labs documented a peer-server tool poisoning attack where poisoned tool descriptions enabled silent exfiltration of WhatsApp chat history.
Affected systems
MCP deployments, Messaging agents, Long-lived agents
Primary threats
Tool Misuse, Data Exfiltration
Impact types
Sensitive chat exfiltration, Cross-tool influence
CVEs
Not specified
What an auditor should now check
- Inspect how tool descriptors are ingested, sanitized, and diffed over time
- Verify untrusted tool metadata cannot silently steer other tools
- Test whether exfiltration-capable tools can be induced through semantic poisoning
Why this matters
This is one of the first concrete proofs that tool descriptors themselves can act like privileged prompt injection inside a multi-tool agent runtime.
What happened
A malicious peer MCP server poisoned tool descriptions so the host agent would exfiltrate WhatsApp history. The attack was semantic rather than memory-unsafe, but the impact was concrete and operational.
Why the classification matters
This is why tool poisoning is not hype. Descriptor text can inherit tool authority when the runtime feeds it directly into model context.
What an auditor should now check
- Whether descriptor text is trusted by default
- Whether multi-tool contexts permit one tool to steer another's invocation
- Whether the system can reconstruct the exact text the model saw during execution
Zealynx takeaway
When the model reads tool text as working context, descriptor text becomes policy-bearing input and deserves audit treatment.
Control implications
- Tool descriptions are part of the attack surface and need sanitization
- Multi-server deployments need cross-tool isolation assumptions challenged
- Logs must preserve the exact descriptor text seen by the model
Affected systems
- MCP deployments
- Messaging agents
- Long-lived agents
Impact types
- Sensitive chat exfiltration
- Cross-tool influence