WhatsApp MCP Bridge Unauthenticated Local API Enables Message Spoofing, File Exfiltration, and DNS Rebinding

Technical Analysis

The whatsapp-bridge component exposes an HTTP API on 127.0.0.1:8080 that Claude (via MCP) uses to send/read WhatsApp messages, but the API lacked authentication and Host header validation, and the `/api/send` endpoint accepted absolute `media_path` values without confinement to a safe directory. This combination allows any co-resident process running as the same OS user — including other MCP servers, IDE extensions, or browser-triggered requests via DNS rebinding — to call the API directly, bypassing the intended trust boundary of 'only the paired MCP client can act.' An attacker can trigger unauthorized message sends from the victim's WhatsApp account or read/exfiltrate arbitrary user-readable files (SSH keys, browser session tokens, source code) by specifying them as `media_path` and having the bridge upload them as WhatsApp document attachments. The lack of Host header validation extends the attack surface to remote attackers via malicious webpages performing DNS rebinding against the loopback service, turning a local-only trust assumption into a network-reachable vulnerability.

Affected Systems

whatsapp-mcp, whatsapp-bridge; protocols: MCP, HTTP

Detection Signatures

• Unauthenticated HTTP requests to 127.0.0.1:8080/api/send or /api/read without bearer token
• Requests to bridge API with absolute or traversal-containing media_path parameters (e.g., paths outside expected media root, '../' sequences)
• Host header values on bridge requests not matching expected local hostname/allow-list (indicative of DNS rebinding attempts)
• Unexpected WhatsApp document sends containing non-media files such as id_rsa, .env, cookie/session store files
• Browser-originated network requests to internal loopback ports from unrelated public web origins

Remediation Steps

1. 1

   Upgrade whatsapp-mcp

   Update to whatsapp-mcp v0.2.1 or later, which introduces bearer token authentication, Host header allow-listing, and media_path confinement.

2. 2

   Restrict bridge exposure

   Stop the whatsapp-bridge service or block loopback access to port 8080 when not actively in use.

3. 3

   Isolate untrusted processes

   Avoid running the bridge alongside untrusted MCP servers, browser extensions, or other unverified local processes sharing the same user session.

4. 4

   Sandbox the bridge

   Run the bridge under a dedicated low-privilege user account or container/sandbox with no access to sensitive files like SSH keys or browser profiles.

5. 5

   Mitigate DNS rebinding exposure

   Avoid browsing untrusted websites while the bridge is running until upgraded, and ensure Host header validation is enforced post-patch.