Proxy Password Leak via HTTP Client: CVE in curl, libsoup, and requests

The password for the proxy is usually kept secret from people: it is not shown in screenshots, not committed to git, and stored in environment variables. However, in 2026, it became clear that it could be leaked by the HTTP client itself. Between April and July, several vulnerabilities were discovered in curl, libcurl, and libsoup, where the Proxy-Authorization header is sent to the wrong proxy, or even directly to the target site. Below is an analysis of the conditions under which this occurs, along with a step-by-step check of your stack.

What Happened: Four Leaks in Four Months

All these bugs are structured similarly: the client remembers the username and password of one proxy and mistakenly sends them further down the chain.

• CVE-2026-6253 (curl and libcurl 7.14.1–8.19.0). If different proxies are configured for http:// and https://, where the first requires a password and the second does not, then during a redirect when changing the scheme, curl will send the credentials of the first proxy to the second. The data is sent in base64, meaning it is effectively in plain text. This was fixed in curl 8.20.0, released on April 29, 2026. The console version of curl is also vulnerable, not just the library.
• CVE-2026-8927 (libcurl 7.12.0–8.20.0). The application reuses one handle for multiple requests, with proxies taken from environment variables, and authorization done via Digest. In this case, the Proxy-Authorization header for proxy A is sent to proxy B, which can then repeat it to impersonate you. This was fixed in curl 8.21.0 on June 24, 2026. The console version of curl is not affected. A nearly identical bug is described in CVE-2026-7168, differing only in how the proxy is selected.
• CVE-2026-12547 (libsoup, SoupAuthManager). libsoup caches proxy credentials without binding them to the host:port address. When proxy settings change (system parameters, WPAD), the old header is sent to the new proxy. Published on July 21, 2026, with a low severity rating.
• CVE-2026-66339 (libsoup, CONNECT tunnels). After establishing a CONNECT tunnel through an HTTP proxy, libsoup attaches Proxy-Authorization to subsequent HTTPS requests within the tunnel. The header is then seen by the target server. CVSS 6.5, published on July 24, 2026.

This issue is not new. In the Python library requests, from version 2.3.0 to 2.31.0 (CVE-2023-32681), the Proxy-Authorization header was sent to the target server during a redirect to HTTPS if the username and password were included directly in the proxy URL. In urllib3, up to versions 1.26.19 and 2.2.2 (CVE-2024-37891), headers set manually, rather than through built-in proxy support, were not stripped during redirects to foreign domains.

Why This Matters for Working with Proxies

For paid proxies, the password is equivalent to money. Whoever obtains it can consume your traffic until you change access. When paying for gigabytes, this is a direct cost, and with shared access across the entire team, it also leads to unauthorized actions from your IP.

The most vulnerable scenarios look like this:

• Scrapers and monitoring tools that automatically follow redirects. The target site or an intermediate redirect can lead the request to a domain that collects headers.
• Scripts with multiple proxies: different proxies for different schemes, switching proxies between requests on the same connection, mixing "password-protected proxies" and "proxies without passwords."
• Long-lived processes on Linux servers, where libcurl and libsoup come with system packages and are updated along with the distribution, rather than with your code.
• Corporate networks with WPAD and PAC files: the proxy changes without the application's involvement, and this specific case is described in CVE-2026-12547.

How to Check Your Stack: Step-by-Step

1. Find out the actual version of libcurl, not just the console version of curl. The command curl -V shows both, but the application may be built with its own copy of the library. For Python with pycurl, run python -c "import pycurl; print(pycurl.version)", and for PHP, call curl_version(). The safe boundary is: 8.21.0 and newer or fixed branches 8.20.1+, 8.16.1+, and 8.14.2+.
2. Check Python dependencies. Run pip show requests urllib3. You need requests version 2.31.0 or higher and urllib3 version 1.26.19 or higher (1.x branch) or 2.2.2 (2.x branch). If the dependency comes transitively, check pip list within the same environment where the scraper runs.
3. Check libsoup on Linux. This applies to GNOME applications, WebKitGTK, and anything built on this stack. Update the package through your distribution's package manager and cross-reference with your distribution's security bulletin: Red Hat lists RHEL 6–10 as affected in the CVE cards.
4. Look for manual header setting in the code. Search for Proxy-Authorization throughout the entire repository. If the header is set manually, rather than through the standard proxy client mechanism (proxies= in requests, ProxyManager in urllib3, CURLOPT_PROXYUSERPWD in libcurl), this is a candidate for leakage during redirects.
5. Look for connection reuse when changing proxies. One libcurl handle, one requests session, or one HTTP agent through which requests with different proxies are sent sequentially. The simplest fix is to use a separate session for each proxy.
6. Disable automatic redirects where they are not needed. In requests, this is allow_redirects=False, in urllib3 redirect=False, and in curl do not set -L and CURLOPT_FOLLOWLOCATION. This way, 3xx responses are handled manually, and you decide where to go next. This workaround is suggested by the authors of requests and urllib3.
7. Conduct a live trap test. Set up a simple HTTP server that prints all incoming headers, and redirect to a second identical server. Run a real scenario through your scraper with the proxy, including changing the scheme from http to https. If either server sees the Proxy-Authorization header, the leak is confirmed in your code, not just theoretically.

Pitfalls

• Docker images live their own lives. You updated curl on the host, but the scraper runs in a container with an old base image. You need to check inside the container: docker exec <container> curl -V.
• The console curl and libcurl are updated differently. CVE-2026-8927 does not affect the console curl, while CVE-2026-6253 does. A fresh curl -V in the terminal says nothing about the library with which your PHP or Python is built.
• Digest does not save you. Yes, with Digest, the password is not sent in plain text. But in CVE-2026-8927, the attacker does not even need the password: the intercepted header is repeated while the nonce is valid.
• Password in URL is convenient but dangerous. The leak in requests manifested specifically when credentials were included in the proxy address in the form user:pass@host:port. This is not a reason to abandon the format, but a reason to keep libraries up to date.
• Redirects may not come from the target. CAPTCHA pages, consent banners, link shorteners, and CDNs also respond with 3xx. The more "follow links" in the crawler, the wider the attack surface.

How to Limit Damage if the Password Does Leak

It is impossible to completely eliminate leaks: tomorrow the next CVE will be released. Therefore, it is important to consider how much one leak costs.

• One project, one access. Do not keep a shared login for all scrapers. In ProxyCove, each purchased proxy receives a separate username and password pair, so the leaked access of one script does not expose the traffic of others.
• Do not keep more traffic on one access than necessary. Replenish gradually based on the task, not for six months in advance.
• Monitor consumption. A sharp increase in traffic without an increase in the number of tasks is the first sign that someone else is using your access.
• Change the password immediately upon suspicion and according to a schedule. How to set this up without downtime is covered in the guide on proxy password rotation.

What Type of Proxy to Choose and Why It Matters

The leak does not depend on the type of proxy: the bug resides in the client. However, the cost of a leak does depend. Data center proxies are cheaper per gigabyte, and for scraping simple sites with frequent redirects, it makes sense to keep them separate from expensive traffic. Residential proxies should be allocated to tasks where they are truly needed, and separate accesses should be created for them with automatic redirects disabled. Mobile proxies, the most expensive per gigabyte, should be kept in code with minimal external dependencies and definitely with version checks for libraries during each build.

Conclusion

The password for the proxy can leak without hacking, without a virus, and without human error: all it takes is outdated libcurl, a redirect to a foreign domain, and a reused connection. The checklist is short: curl and libcurl from 8.21.0, requests from 2.31.0, urllib3 from 1.26.19 or 2.2.2, updated libsoup, a separate session for each proxy, redirects under control, and one live trap test. Plus, a separate access for each project, so that one leak costs one script, not the entire balance.