WhatsApp MCP Flaw (CVE-2026-46555) Exposes SSH Keys, Enables Message Hijacking

A critical flaw in the popular open-source WhatsApp-MCP project lets any process on a victim’s machine or even a malicious website hijack a paired WhatsApp account and siphon off sensitive local files, according to a security advisory published on GitHub on May 16, 2026.

The vulnerability, tracked as CVE-2026-46555 and rated High severity, lives in the whatsapp-bridge HTTP API that ships with versions 0.2.0 and earlier of the verygoodplugins/whatsapp-mcp package.

The bridge listens on 127.0.0.1:8080 with zero authentication and no Host header validation, meaning any code capable of reaching that port could impersonate a legitimate client.

WhatsApp MCP Flaw

Compounding this, the /api/send endpoint accepted an absolute media_path parameter without restricting it to a safe directory, opening the door to classic path traversal abuse under CWE-22.

Researchers identified a chain of practical attack scenarios stemming from these two design gaps:

Any local process running as the same OS user as the bridge could send WhatsApp messages from the paired account without ever needing credentials.
The same access lets attackers read arbitrary files the user could access, SSH private keys, browser session tokens, source code, and dotfiles, then exfiltrate them disguised as WhatsApp document attachments.
A remote attacker could trigger identical behavior purely through DNS rebinding from a malicious webpage, since the bridge never checked where requests actually originated.

This flaw is particularly instructive for the growing Model Context Protocol ecosystem, where “local caller” no longer means just apps the user knowingly launched.

The advisory notes that sibling MCP servers, IDE extensions, and other tool-triggered flows running inside a user’s AI-assisted session can all act as an effective caller against an unauthenticated bridge.

This mirrors a broader pattern documented by Invariant Labs in 2025, which showed that an untrusted MCP server could manipulate an AI agent into leaking WhatsApp message history entirely through legitimate tool-chaining, without breaking any encryption.

The lesson across both incidents: MCP servers handling sensitive integrations cannot rely on network position or process boundaries alone; they need explicit trust segmentation between tools.

The maintainer, GitHub user jack-arturo, shipped a patched release on May 16, 2026, addressing all three underlying weaknesses in one update.

Weakness	Original Flaw	Fix in v0.2.1
CWE-306 (No Auth)	Bridge API open to any local caller	Bearer token auth via environment variable, constant-time validation
CWE-346 (Origin Validation)	No Host header check, DNS rebinding possible	Host header allow-list enforcement
CWE-22 (Path Traversal)	Absolute media_path accepted unchecked	media_path confined to configured root, traversal sequences rejected

The advisory flags this as a breaking change for existing bridge API clients, with migration steps detailed in the v0.2.1 release notes on GitHub.

For teams unable to upgrade immediately, the advisory recommends stopping the bridge or blocking loopback access to port 8080 when not in active use, avoiding running it alongside untrusted MCP servers or browser extensions, steering clear of untrusted sites.

while the bridge runs, and isolating the bridge in a dedicated user account or sandboxed container with no access to sensitive files. The vulnerability was reported privately by researcher Paul van der Klooster before public disclosure.