CVE-2026-32116: 
Python vulnerability analysis and mitigation

CVE-2026-32116 is a path traversal vulnerability in Magic Wormhole, a Python-based peer-to-peer file transfer tool, that allows a malicious sender to overwrite arbitrary local files on the receiver's system during a wormhole receive operation. The vulnerability affects versions 0.21.0 through 0.22.x (specifically 0.21.0, 0.21.1, and 0.22.0) and was introduced in the 0.21.0 release on October 23, 2025. It was disclosed on March 12, 2026, and fixed in version 0.23.0. The CVSS v3.1 base score is 8.1 (High) and the CVSS v4.0 base score is 8.2 (High) (GitHub Advisory, Security Advisory).

The root cause is a missing basename() sanitization check on the receiver side, classified as CWE-22 (Improper Limitation of a Pathname to a Restricted Directory — Path Traversal). During a refactoring in version 0.21.0, the receiver-side call to basename() — which strips path components from the sender-supplied filename — was accidentally dropped. Well-behaved senders compute the filename from basename() of the sent file, but a malicious sender can craft a filename containing path traversal sequences (e.g., ../../.ssh/authorized_keys) that the receiver will write to verbatim. The attack is constrained to the sender role in the wormhole transaction; transit/relay servers and other third parties cannot exploit this due to the wormhole protocol's end-to-end encryption (GitHub Advisory, Security Advisory).

A malicious sender can overwrite arbitrary files accessible to the receiving user's account, with high-impact targets including ~/.ssh/authorized_keys (enabling unauthorized SSH access) and shell configuration files like .bashrc (enabling persistent arbitrary command execution on next login). There is no confidentiality impact, but integrity is severely compromised on both the vulnerable and subsequent systems. The attack requires the victim to initiate a wormhole receive operation, but once triggered, the file write occurs without further user confirmation (GitHub Advisory, Security Advisory).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at this time. The EPSS score is approximately 0.046–0.113%, placing it in the 29th percentile for exploitation likelihood within 30 days. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires social engineering the victim into accepting a wormhole transfer from the attacker, which limits opportunistic exploitation but makes targeted attacks feasible (GitHub Advisory, Feedly).

1. Setup: The attacker installs Magic Wormhole (any version, including patched) and prepares a malicious file payload.
2. Craft malicious filename: The attacker creates or renames a file with a path traversal sequence as its name, such as ../../.ssh/authorized_keys, containing the attacker's SSH public key as content.
3. Initiate wormhole send: The attacker runs wormhole send with the malicious file, which generates a one-time wormhole code (e.g., 7-crossword-clockwork).
4. Social engineering: The attacker convinces the victim to run wormhole receive 7-crossword-clockwork, presenting the transfer as a legitimate file share.
5. Exploit path traversal: Because the receiver-side basename() check is absent in versions 0.21.0–0.22.x, the receiver writes the file contents to the attacker-specified path (e.g., ~/.ssh/authorized_keys), overwriting the victim's SSH authorized keys with the attacker's public key.
6. Achieve persistence: The attacker now has SSH access to the victim's system using their private key, or if .bashrc was targeted, arbitrary commands execute on the victim's next shell login (GitHub Advisory, Security Advisory).

• File System: Unexpected modification timestamps on ~/.ssh/authorized_keys or ~/.bashrc coinciding with a wormhole receive operation; presence of unknown SSH public keys in ~/.ssh/authorized_keys; new or modified shell configuration files (.bashrc, .bash_profile, .profile) with unfamiliar content.
• Logs: Shell history showing wormhole receive commands; SSH authentication logs (/var/log/auth.log or /var/log/secure) showing successful logins from previously unknown IP addresses or SSH keys shortly after a wormhole transfer.
• Process: Unexpected processes spawned from shell sessions initiated after a wormhole receive event, particularly if .bashrc was overwritten with malicious commands.

Upgrade Magic Wormhole to version 0.23.0 or later, which restores the receiver-side basename() check and adds a unit test to prevent regression (GitHub Advisory). As an immediate workaround without upgrading, always specify the output filename explicitly using the --output or -o flag on every invocation: wormhole receive -o <safe-filename>. This forces the file to be written to the specified local path regardless of the sender-supplied filename. Additionally, restrict wormhole usage to trusted parties only, and implement file integrity monitoring on critical files such as ~/.ssh/authorized_keys and shell configuration files (Security Advisory).

The vulnerability was discovered and reported by Ian McKenzie (@ikmckenz), who also provided a fix, and was published by project maintainer warner on March 12, 2026. The advisory was picked up by automated CVE tracking services and discussed briefly on Bluesky. No major media coverage or significant researcher commentary beyond the initial advisory has been identified (Security Advisory).