Monitor vulnerabilities like this one.
Sign up free to get alerted when software you use is affected.
8.2
Magic Wormhole: Malicious File Overwrite Using 'wormhole receive'
CVE-2026-32116
GHSA-4g4c-mfqg-pj8r
Summary
A vulnerability in Magic Wormhole allows a malicious sender to overwrite local files, potentially compromising a receiver's computer. This can happen when a receiver uses the 'wormhole receive' command without a custom output file specified. To fix this, update Magic Wormhole to version 0.23.0 or use the '--output' option when running 'wormhole receive' to ensure the file is saved to a specific location.
What to do
- Update magic-wormhole to version 0.23.0.
Affected software
| Vendor | Product | Affected versions | Fix available |
|---|---|---|---|
| – | magic-wormhole | > 0.21.0 , <= 0.23.0 | 0.23.0 |
Original title
Magic Wormhole: "wormhole receive" allows arbitrary local file overwrite
Original description
### Impact
_What kind of vulnerability is it? Who is impacted?_
Receiving a file (`wormhole receive`) from a malicious party could result in overwriting critical local files, including `~/.ssh/authorized_keys` and `.bashrc`. This could be used to compromise the receiver's computer.
Only the sender of the file (the party who runs `wormhole send`) can mount the attack. Other parties (including the transit/relay servers) are excluded by the wormhole protocol.
### Patches
_Has the problem been patched? What versions should users upgrade to?_
The bug has been fixed in magic-wormhole 0.23.0. All users should upgrade to this version.
The vulnerability first surfaced in the 0.21.0 release on 23-Oct-2025.
### Workarounds
_Is there a way for users to fix or remediate the vulnerability without upgrading?_
As a workaround, the receiver can override the sender's filename with the `--output` or `-o` option. For example: `wormhole receive -o shopping-list.txt` will write the file to `shopping-list.txt` in the local directory, regardless of what the sender tries to do. To be effective, this option must be added to every invocation of `wormhole receive` / `wormhole rx`.
### References
_Are there any links users can visit to find out more?_
Incoming file transfer requests include a `filename`, used to decide where the file contents will be written. Well-behaving senders compute this from the `basename()` of the sent file (which discards all but the last segment of the path). To guard against malicious senders, the receiver also applies `basename()` to the incoming filename. During refactoring in version 0.21.0, this receiver-side check was accidentally dropped. The check was restored in version 0.23.0 along with a unit test.
Many thanks to Ian McKenzie (@ikmckenz) for spotting the bug and reaching out with a fix.
_What kind of vulnerability is it? Who is impacted?_
Receiving a file (`wormhole receive`) from a malicious party could result in overwriting critical local files, including `~/.ssh/authorized_keys` and `.bashrc`. This could be used to compromise the receiver's computer.
Only the sender of the file (the party who runs `wormhole send`) can mount the attack. Other parties (including the transit/relay servers) are excluded by the wormhole protocol.
### Patches
_Has the problem been patched? What versions should users upgrade to?_
The bug has been fixed in magic-wormhole 0.23.0. All users should upgrade to this version.
The vulnerability first surfaced in the 0.21.0 release on 23-Oct-2025.
### Workarounds
_Is there a way for users to fix or remediate the vulnerability without upgrading?_
As a workaround, the receiver can override the sender's filename with the `--output` or `-o` option. For example: `wormhole receive -o shopping-list.txt` will write the file to `shopping-list.txt` in the local directory, regardless of what the sender tries to do. To be effective, this option must be added to every invocation of `wormhole receive` / `wormhole rx`.
### References
_Are there any links users can visit to find out more?_
Incoming file transfer requests include a `filename`, used to decide where the file contents will be written. Well-behaving senders compute this from the `basename()` of the sent file (which discards all but the last segment of the path). To guard against malicious senders, the receiver also applies `basename()` to the incoming filename. During refactoring in version 0.21.0, this receiver-side check was accidentally dropped. The check was restored in version 0.23.0 along with a unit test.
Many thanks to Ian McKenzie (@ikmckenz) for spotting the bug and reaching out with a fix.
nvd CVSS4.0
8.2
Vulnerability type
CWE-22
Path Traversal
Published: 13 Mar 2026 · Updated: 14 Mar 2026 · First seen: 12 Mar 2026