What happened
A GitHub Security Advisory (CVE-2026-46555, CVSS 7.7) published 2026-07-20 details how the WhatsApp MCP Server's local HTTP bridge — used to let Claude read/send WhatsApp messages — had no authentication, enabling any co-located process or remote attacker (via DNS rebinding) to hijack the paired WhatsApp account and exfiltrate arbitrary local files.
Why it matters
This illustrates a recurring MCP-ecosystem failure pattern: local 'trusted-by-default' bridge servers granting AI agents access to sensitive personal services (messaging, files) with no authentication, where the MCP threat model of 'any local caller' now includes other MCP servers and IDE extensions sharing the user's session — turning a convenience integration into a path for credential/file exfiltration and account takeover.
Attack vector
The whatsapp-bridge HTTP API listens on 127.0.0.1:8080 without authentication or Host header validation, and its /api/send endpoint accepts an absolute media_path without directory confinement. Any local process running as the same user (including sibling MCP servers, IDE extensions, or other agent-triggered flows) can send WhatsApp messages from the paired account or exfiltrate arbitrary user files (SSH keys, browser session data, source code) as WhatsApp attachments; lack of Host header validation also enables DNS-rebinding attacks from a malicious webpage.
Affected systems
WhatsApp MCP Server (whatsapp-mcp), versions prior to 0.2.1
Mitigation
Upgrade to whatsapp-mcp v0.2.1, which adds bearer-token authentication, Host header allow-listing, and media_path directory confinement. Users unable to upgrade should stop the bridge when not in use, block loopback port 8080, and avoid running untrusted MCP servers/browsing untrusted sites while the bridge is active.