Path Traversal in file:// protocol allows Arbitrary File Read

How it was found

Summary:

The file:// protocol handler in curl does not properly sanitise or block path traversal sequences (../). This allows a maliciously crafted file:// URL to escape the intended directory and access arbitrary files on the filesystem with the permissions of the user running curl.

When curl is used as a library by another application (e.g., a web server backend) that processes user-supplied URLs, this can be escalated to a remote, arbitrary file read vulnerability.

No AI was used to find this issue or generate this report.

Affected version

This was reproduced on the latest master branch, commit [c3add7130d7d81add205edbbb75fdfd1f38b3c68]. curl -V output: curl 8.18.0-DEV (x86_64-pc-linux-gnu) libcurl/8.18.0-DEV OpenSSL/3.5.4 zlib/1.3.1 libpsl/0.21.2 Release-Date: [unreleased] Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp ws wss Features: alt-svc AsynchDNS HSTS HTTPS-proxy IPv6 Largefile libz NTLM PSL SSL threadsafe TLS-SRP UnixSockets

Platform: Debian GNU/Linux 13 (trixie ) running on x86_64.

Steps To Reproduce:

1. Clone and build the latest version of curl from the master branch.
2. From the project's root directory, run the following command:

   ./src/curl "file:///any/dummy/path/../../../../../../etc/passwd"
   

3. Expected Result: curl should fail with an error, stating that the file was not found or that the path is invalid, as it should sanitise the ../ sequences.
4. Actual Result: curl successfully traverses up the directory tree and prints the contents of the /etc/passwd file to standard output.

Supporting Material/References:

A screenshot of the terminal output is attached.

Impact

This path traversal vulnerability allows for arbitrary file read. While the impact is limited when run directly by a user on the command line, it becomes High or Critical when libcurl is used by another application that constructs file:// URLs from untrusted user input.

A remote attacker could abuse this to:

• Read sensitive configuration files (e.g., config.php, .env) containing database credentials, API keys, etc.
• Read application source code to find other vulnerabilities.
• Read system files like /etc/passwd, /etc/shadow (if running with sufficient privileges).
• Read private SSH keys or other sensitive user data.

This breaks the security boundary that should be enforced by the file:// handler, turning any application that uses it for local file access into a potential vector for total server information disclosure.