EUVD-2026-33646
GHSA-frgv-ppw5-432r
Severity by source
CVSS:4.0/AV:A/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Primary rating from NVD · only source for this CVE.
CVSS VectorNVD
CVSS:4.0/AV:A/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Lifecycle Timeline
2DescriptionCVE.org
A vulnerability was determined in lharries whatsapp-mcp 0.0.1. Affected by this vulnerability is the function SendMessageRequest of the file whatsapp-bridge/main.go of the component Send API Endpoint. This manipulation of the argument mediaPath causes path traversal. The exploit has been publicly disclosed and may be utilized. Patch name: 6657cdceadd361e8fbe824afe9d00b4504009a5d. It is recommended to apply a patch to fix this issue.
AnalysisAI
Path traversal in whatsapp-mcp 0.0.1 exposes arbitrary server files to authenticated adjacent-network attackers via the mediaPath argument of the Send API endpoint (/api/send). The sendWhatsAppMessage function in whatsapp-bridge/main.go passed the caller-supplied path directly to os.ReadFile() without sanitization, allowing traversal sequences to reference files outside any intended directory. A proof-of-concept exploit has been publicly disclosed (CVSS 4.0 E:P), though no active exploitation is confirmed and no CISA KEV listing exists. The overall CVSS 4.0 score of 2.0 reflects narrow real-world impact: adjacent-network exposure only, low confidentiality loss, and no integrity or availability impact.
Technical ContextAI
The vulnerable code is in whatsapp-bridge/main.go within the sendWhatsAppMessage function, where the mediaPath field of a SendMessageRequest struct is consumed by os.ReadFile(mediaPath) without prior validation. CWE-22 (Improper Limitation of a Pathname to a Restricted Directory) is the root cause: the application trusts attacker-controlled input to construct a filesystem path. The commit diff reveals two additional traversal surfaces also fixed in the same patch: (1) the chatJID parameter used in fmt.Sprintf("store/%s", ...) without sanitization, and (2) document filenames extracted via doc.GetFileName() used without filepath.Base() isolation. Critically, the server previously bound to 0.0.0.0:port (all interfaces), which is why the CVSS 4.0 vector sets AV:A (Adjacent Network) rather than AV:L (Local) - the REST API was reachable from other hosts on the LAN. The fix binds the server exclusively to 127.0.0.1, collapsing the network attack surface to loopback-only post-patch.
RemediationAI
Apply the upstream fix available at commit 6657cdceadd361e8fbe824afe9d00b4504009a5d (https://github.com/BenGedi/whatsapp-mcp/commit/6657cdceadd361e8fbe824afe9d00b4504009a5d), submitted as pull request #1 against the upstream repository (https://github.com/lharries/whatsapp-mcp/pull/1). No tagged patched release version has been confirmed - this is an upstream fix commit only, not a versioned release. If applying the patch directly is not possible, operators should immediately restrict network access to the REST server port using host-based firewall rules (e.g., iptables -A INPUT -p tcp --dport <PORT> ! -s 127.0.0.1 -j DROP) to prevent adjacent-network exploitation - this replicates the loopback-binding change included in the fix. Note that this workaround does not eliminate the path traversal logic flaw; it only reduces the attack surface. Running the bridge process under a least-privilege OS user account limits the files an attacker can read if exploitation occurs. The patch also includes floor pins for h11>=0.16.0 and urllib3>=2.5.0 in whatsapp-mcp-server/pyproject.toml to address separate transitive dependency CVEs; these should be verified after applying the fix.
Same weakness CWE-22 – Path Traversal
View allSame technique Path Traversal
View allShare
External POC / Exploit Code
Leaving vuln.today