CVE-2026-46555: WhatsApp MCP Server Path Traversal Flaw

CVE-2026-46555 Overview

CVE-2026-46555 affects the WhatsApp MCP Server, a Model Context Protocol (MCP) server that enables Claude to read and send WhatsApp messages. Versions prior to 0.2.1 expose the whatsapp-bridge HTTP API on 127.0.0.1:8080 without authentication or Host header validation. The /api/send endpoint also accepts an absolute media_path parameter without confining it to a safe directory. Any local process running as the same user as the bridge can send WhatsApp messages from the paired account and exfiltrate arbitrary user-readable files as document attachments. Remote attackers can trigger the same operations through DNS rebinding against a browsing user.

Critical Impact
Attackers gain unauthorized WhatsApp message sending and arbitrary file exfiltration (SSH keys, browser session data, source code, dotfiles) from the victim's account through a local process or DNS rebinding attack.

Affected Products

whatsapp-mcp (verygoodplugins) versions prior to 0.2.1
whatsapp-bridge HTTP API component bundled with the MCP server
Corresponding Docker images and release artifacts prior to v0.2.1

Discovery Timeline

2026-07-20 - CVE-2026-46555 published to the National Vulnerability Database (NVD)
2026-07-23 - Last updated in NVD database

Technical Details for CVE-2026-46555

Vulnerability Analysis

The WhatsApp MCP Server bridge exposes an HTTP API on the loopback interface without any authentication layer. Loopback binding is treated as an implicit security boundary, but on a multi-process user session, that assumption fails. Any process running under the same user can issue arbitrary API requests to the bridge.

The /api/send endpoint compounds the issue by accepting an absolute media_path parameter. The parameter is not restricted to a safe root, and path traversal sequences are not filtered. This turns the send-media capability into an arbitrary file read primitive, with WhatsApp itself acting as the exfiltration channel.

In MCP deployments, the caller pool is broader than user-launched processes. Sibling MCP servers, IDE extensions, and tool-triggered flows all share the user session and can invoke the bridge. Additionally, the absence of Host header validation permits DNS rebinding — a malicious webpage can, after DNS TTL expiry, resolve its own hostname to 127.0.0.1 and issue browser-originated requests against the bridge.

Root Cause

The vulnerability combines two distinct weaknesses. First, missing authentication and missing Host header validation on a loopback-bound HTTP service. Second, an [CWE-22] path traversal flaw in the media_path parameter of /api/send, which permits absolute paths and traversal outside any intended media directory.

Attack Vector

A local caller sends an HTTP POST to http://127.0.0.1:8080/api/send with a target WhatsApp recipient and a media_path set to any file readable by the bridge user, such as ~/.ssh/id_rsa or browser cookie stores. The bridge reads the file and dispatches it as a WhatsApp document attachment to the attacker-controlled recipient. For remote exploitation, the attacker hosts a webpage with DNS rebinding logic that redirects the origin's hostname to 127.0.0.1:8080 and issues the same request from the victim's browser.

No verified proof-of-concept code is published. See the GitHub Security Advisory GHSA-7jj9-4qqq-4xc4 for full technical details.

Detection Methods for CVE-2026-46555

Indicators of Compromise

Unexpected WhatsApp document messages sent from the paired account, especially attachments containing dotfiles, keys, or source code
HTTP requests to 127.0.0.1:8080/api/send from processes other than the intended MCP client
Outbound WhatsApp traffic correlated with reads of sensitive files such as ~/.ssh/, browser profile directories, or credential stores
DNS responses that resolve external hostnames to 127.0.0.1 while a browser session is active

Detection Strategies

Monitor process activity on hosts running whatsapp-bridge for unauthorized connections to loopback port 8080
Alert on file read events targeting sensitive paths by the bridge process shortly before outbound WhatsApp network activity
Inspect the bridge's request logs for /api/send calls containing absolute paths or .. traversal sequences in the media_path field

Monitoring Recommendations

Enable process-level telemetry on developer workstations to correlate MCP tool invocations with sensitive file access
Log all HTTP requests to the bridge and forward them to a centralized platform for retention and analysis
Track browser DNS resolution events for short-TTL domains that pivot to loopback addresses, a signature of DNS rebinding attempts

How to Mitigate CVE-2026-46555

Immediate Actions Required

Upgrade whatsapp-mcp to version 0.2.1 or later, including replacement of any pinned Docker images
Configure the new bearer token via the required environment variable and rotate it if the prior deployment was exposed
Audit the paired WhatsApp account's sent-message history for unauthorized document attachments
Restrict the configured media_path root to a dedicated directory that contains no sensitive files

Patch Information

The fix ships in whatsapp-mcp v0.2.1 and corresponding Docker images and release artifacts. The patch introduces bearer token authentication on the bridge HTTP API, configured via environment variable, required on all requests, and validated with constant-time comparison. It adds Host header allow-list validation to block DNS rebinding, and it confines media_path to a configured directory while rejecting absolute paths outside the root and path traversal sequences. The upgrade is a breaking change for bridge API clients. Refer to the GitHub Release v0.2.1 notes and the project security document.

Workarounds

Stop the bridge or block loopback access to port 8080 when the bridge is not actively in use
Do not run the bridge alongside untrusted MCP servers, browser extensions, or other untrusted local processes
Avoid browsing untrusted sites while the bridge is running to mitigate DNS rebinding exposure
Run the bridge under a dedicated user account or inside a sandbox or container with no access to sensitive files

bash

# Configuration example: restrict bridge exposure until upgrade
# Block loopback access to the bridge port when idle (Linux, iptables)
sudo iptables -A INPUT -i lo -p tcp --dport 8080 -j DROP

# After upgrading to v0.2.1, configure the required bearer token
export WHATSAPP_BRIDGE_TOKEN="$(openssl rand -hex 32)"
export WHATSAPP_MEDIA_ROOT="/var/lib/whatsapp-mcp/media"