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.
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.
https://curl.haxx.se/docs/adv_2018-b3bf.html https://github.com/curl/curl/commit/af32cd3859336ab963591ca0df9b1e33a7ee066b
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. 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 --location-trusted with the curl command line tool.
Vulmon