curl / Docs / curl CVEs / SMB access smuggling via FILE URL on Windows
Awarded 400 USD


SMB access smuggling via FILE URL on Windows

Project curl Security Advisory, January 8th 2020 - Permalink


As of March 2020, the curl security team has reconsidered this issue and we no longer consider this a curl security flaw. This "SMB access" (that also can be done using other network protocols) is a Windows feature that cannot be avoided or switched off by an application or library and we have stopped trying. All and any such network accesses via file accesses are no longer considered a curl bug, but a Windows feature. curl and libcurl on Windows that uses FILE:// URLs might generate such probes.

For the sake of history, we keep the advisory as it was originally stated below.


libcurl can be told to load a file from a FILE:// URL. It then loads the file from the path specified in the URL from the local file system.

If you craft the given path so that it starts with two slashes (or backslashes) followed by a hostname, Windows systems automatically treats that as a request to access the hostname using SMB instead of reading a local file with that name. This is not expected nor documented libcurl behavior.

Applications allowing users to provide URLs or parts of URLs could be vulnerable to this flaw. Both the curl tool and library.

Example URL exploiting this: file://localhost//hostname/home/secret.txt.


This bug only exists when libcurl runs on a Microsoft Windows operating system.

This bug exists in the first code import we have, from 1999.

The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2019-15601 to this issue.

CWE-20: Improper Input Validation

Severity: Low


libcurl is used by many applications, but not always advertised as such.



We suggest you take one of the following actions immediately, in order of preference:

A - Upgrade curl to version 7.68.0

B - Apply the patch to your version and rebuild

C - do not use FILE:// URLs


The issue was reported to the curl project on October 31, 2019. The initial fix was done, verified and communicated with the reporter on November 7, 2019.

This advisory was posted on January 8th 2020.


Thanks a lot!