CVE-2026-80256: wcurl backslash bypass

How it was found

At https://github.com/curl/curl/blob/curl-8_21_0/scripts/wcurl#L198, get_url_filename() protects percent-encoded %2F and %5C, but leaves a literal backslash unchanged before it becomes the automatic output filename.

On Windows, run wcurl.bat "http://127.0.0.1:PORT/sub\..\..\escaped.txt" from sandbox\inside while a local server returns a marker; curl exits 0 and creates sandbox\escaped.txt outside the working directory.

I reproduced this twice on native Windows 10 build 19045 using the current official curl 8.21.0_7 x64 archive, including its shipped wcurl.bat, wcurl, and curl.exe.

The control URL ending sub%5C..%5C..%5Cescaped.txt stays inside the working directory, so the published CVE-2025-11563 percent-encoding repair works while the literal-backslash bypass remains.

To rerun it, extract the official archive, obtain busybox64u.exe from https://github.com/rmyorston/busybox-w32, then run python3 02-poc-wcurl-literal-backslash.py --curl-bin ./curl-8.21.0_7-win64-mingw/bin --busybox ./busybox64u.exe --work-dir ./poc-output.

I used AI to assist the source audit and drafting, and personally reran the release proof, control, current-tree check, and all 28 upstream tests.

Impact

An attacker-controlled URL can make wcurl create a new attacker-controlled file outside the directory chosen by a Windows user, subject to that user's filesystem permissions and the target not already existing; modern curl's --no-clobber prevents overwriting an existing target.