Description
Affected Warp versions via affected WSL builds contain an OS command injection vulnerability in the WSL URL-opening fallback. When Warp is running under WSL and cannot open a URL through wslview, it falls back to a Windows command processor path. A URL controlled through terminal output can reach that fallback when the user opens the link.
Impact
Successful exploitation may allow commands to run on the Windows host as the current Windows user. Exploitation requires user interaction: the user must open a malicious link displayed in Warp. The issue affects WSL configurations where wslview is unavailable and the user has not opted into opening links through the WSL browser path. Native macOS, native Windows, non-WSL Linux sessions, WSL sessions with working wslview, and WSL sessions with WARP_FORCE_WSL_BROWSER set are not affected by this command path.
Patch
The patch parses and validates URLs before handing them to the Windows opener, allows only http and https schemes, uses the parser's serialized URL form, and replaces the command-processor fallback with a Windows URL handler invocation.
Workarounds
Install wslu so wslview is available, or set WARP_FORCE_WSL_BROWSER=1 to avoid the Windows-host fallback. Users should still update to a patched Warp build.
Credits
Thanks to the following reporter who responsibly disclosed this issue:
References
Description
Affected Warp versions via affected WSL builds contain an OS command injection vulnerability in the WSL URL-opening fallback. When Warp is running under WSL and cannot open a URL through
wslview, it falls back to a Windows command processor path. A URL controlled through terminal output can reach that fallback when the user opens the link.Impact
Successful exploitation may allow commands to run on the Windows host as the current Windows user. Exploitation requires user interaction: the user must open a malicious link displayed in Warp. The issue affects WSL configurations where
wslviewis unavailable and the user has not opted into opening links through the WSL browser path. Native macOS, native Windows, non-WSL Linux sessions, WSL sessions with workingwslview, and WSL sessions withWARP_FORCE_WSL_BROWSERset are not affected by this command path.Patch
The patch parses and validates URLs before handing them to the Windows opener, allows only
httpandhttpsschemes, uses the parser's serialized URL form, and replaces the command-processor fallback with a Windows URL handler invocation.Workarounds
Install
wslusowslviewis available, or setWARP_FORCE_WSL_BROWSER=1to avoid the Windows-host fallback. Users should still update to a patched Warp build.Credits
Thanks to the following reporter who responsibly disclosed this issue:
References
v0.2026.05.13.09.15.stable_01