cURL HTTP Redirect Processing May Let Remote Users Obtain Potentially Sensitive Information from Custom Authentication Headers
SecurityTracker Alert ID: 1040274|
SecurityTracker URL: http://securitytracker.com/id/1040274
(Links to External Site)
Date: Jan 25 2018
Disclosure of authentication information, Disclosure of system information|
Fix Available: Yes Vendor Confirmed: Yes |
Version(s): 7.1 - 7.57.0|
A vulnerability was reported in cURL. A remote user can obtain potentially sensitive information on the target system.|
When sending custom headers in an HTTP request and an HTTP 30X redirect response code is received, libcurl sends the custom headers to the server specified in the 'Location:' response header. A remote user may be able to obtain potentially sensitive authentication information from applications that use custom 'Authorization:' headers.
The vendor was notified on January 18, 2018.
Craig de Stigter reported this vulnerability.
A remote user may be able to obtain potentially sensitive authentication information from applications that use custom 'Authorization:' headers.|
The vendor has issued a fix (7.58.0).|
The vendor advisory is available at:
Vendor URL: curl.haxx.se/docs/adv_2018-b3bf.html (Links to External Site)
Access control error|
|Underlying OS: Linux (Any), UNIX (Any), Windows (Any)|
This archive entry has one or more follow-up message(s) listed below.|
Source Message Contents
Subject: [oss-security] [SECURITY ADVISORY] curl: HTTP authentication leak in redirects|
HTTP authentication leak in redirects
Project curl Security Advisory, January 24th 2018 -
libcurl might leak authentication data to third parties.
When asked to send custom headers in its HTTP requests, libcurl will send that
set of headers first to the host in the initial URL but also, if asked to
follow redirects and a 30X HTTP response code is returned, to the host
mentioned in URL in the `Location:` response header value.
Sending the same set of headers to subsequest hosts is in particular a problem
for applications that pass on custom `Authorization:` headers, as this header
often contains privacy sensitive information or data that could allow others
to impersonate the libcurl-using client's request.
We are not aware of any exploit of this flaw.
This bug has existed since before curl 6.0. It existed in the first commit we
have recorded in the project.
The Common Vulnerabilities and Exposures (CVE) project has assigned the name
CVE-2018-1000007 to this issue.
- Affected versions: libcurl 7.1 to and including 7.57.0
- Not affected versions: libcurl >= 7.58.0
libcurl is used by many applications, but not always advertised as such.
In libcurl version 7.58.0, custom `Authorization:` headers will be limited the
same way other such headers is controlled within libcurl: they will only be
sent to the host used in the original URL unless libcurl is told that it is ok
to pass on to others using the `CURLOPT_UNRESTRICTED_AUTH` option.
**NOTE**: this solution creates a slight change in behavior. Users who
actually want to pass on the header to other hosts now need to give curl that
specific permission. You do this with
with the curl command line tool.
A [patch for
We suggest you take one of the following actions immediately, in order of
A - Upgrade curl to version 7.58.0
B - Apply the patch to your version and rebuild
C - Do not enable CURLOPT_FOLLOWLOCATION if you pass on custom Authorization
It was reported to the curl project on January 18, 2018
We contacted distros@openwall on January 19.
curl 7.58.0 was released on January 24 2018, coordinated with the publication
of this advisory.
Reported by Craig de Stigter. Patch by Daniel Stenberg.
Thanks a lot!