CVE-2026-6253: proxy credentials leak over redirect-to proxy
What the report claims
A redirecting server can cause libcurl to disclose credentials intended for one proxy to a different proxy under separate administrative control.
Compare with curl's recorded outcome
Known vulnerability
A real vulnerability: CVE-2026-6253 proxy credentials leak over redirect-to proxy
Shown for comparison after analysis. The pipeline did not see this label.
ProveIt's finding
The available evidence does not settle the report. A maintainer should investigate.
Why this finding?
- The report describes a specific, plausible credential leak across proxy trust boundaries during redirect-induced proxy re-selection.
- The provided curl source code excerpt contains only the CURLPROXY_HTTPS constant definition (include/curl/curl.h:794). None of the implementation code for proxy URL parsing, credential extraction, redirect handling, per-transfer state management, or Proxy-Authorization header generation is included.
- Deterministic checks only confirm CURLOPT_PROXYUSERNAME and CURLOPT_PROXYPASSWORD exist, but the report explicitly states the issue is about credentials embedded in the proxy URL (http://user:pass@proxy), not those global options.
- A human reviewer needs to examine the proxy handling and redirect code (likely in lib/http_proxy.c, lib/url.c, lib/transfer.c) to determine if proxy credentials from the original proxy URL are incorrectly retained in per-transfer state when the proxy changes due to a scheme change (http→https).
What still needs checking
- Source code for proxy URL parsing and credential extraction (likely lib/url.c or lib/http_proxy.c)
- Source code for proxy selection based on URL scheme (http_proxy vs https_proxy)
- Source code for redirect handling and per-transfer state reset/cleanup
- Source code for Proxy-Authorization header generation during CONNECT to proxy
How this analysis ran 6 claims · 0 citations verified
Checked against curl master on 2026-04-13 (70bb0db76720). Dev evaluation split. Citation verification checks that a referenced line was in the evidence; it does not prove the model interpreted it correctly.
Review a draft reply to the reporter
Edit and verify before sending.
Thank you for the detailed report and reproduction steps. The provided code excerpt for triage only includes the CURLPROXY_HTTPS constant definition. To evaluate the claim, we need to examine the proxy URL parsing, credential extraction, redirect handling, and Proxy-Authorization generation code (likely in lib/http_proxy.c, lib/url.c, lib/transfer.c). Could you indicate which functions you believe are involved, or we will have a maintainer review the relevant proxy/redirect code paths?
Inspect all claims and source code 6 claims · 1 code excerpts
Report claims
Proxy credentials learned from the originally selected proxy URL can remain in per-transfer state and be reused for the next proxy after a redirect changes proxy selection.
Read the reasoning
The provided source code only shows the definition of CURLPROXY_HTTPS (include/curl/curl.h:794). The implementation code for proxy selection, credential extraction from proxy URLs, per-transfer state management during redirects, and Proxy-Authorization header generation is not included in the provided source. Without the relevant functions (likely in lib/http_proxy.c, lib/url.c, or lib/transfer.c), the claim cannot be verified or contradicted.
The issue occurs when a redirect switches from an http:// URL to an https:// URL, causing libcurl to reuse credentials from the http_proxy to the https_proxy.
Read the reasoning
Same as C1: the code that handles proxy selection based on URL scheme (http vs https) and credential reuse across proxy changes during redirects is not provided. The symbols CURLOPT_PROXY and CURLOPT_HTTPS_PROXY are mentioned but their handling code is absent.
A redirect from http:// to https:// that changes the proxy selection from http_proxy to https_proxy triggers the reuse of credentials.
Read the reasoning
The redirect handling logic that triggers proxy re-selection and the code path that fails to clear proxy credentials when the proxy changes are not in the provided source.
Proxy-B receives Proxy-Authorization: Basic dXNlcjpwYXNz on its first request, even though its URL contains no credentials.
Read the reasoning
The CONNECT request generation and Proxy-Authorization header construction code is not provided. The claim describes observed behavior that would be decided by proxy connection setup code not shown.
Run curl with http_proxy=http://user:pass@127.0.0.1:8081 and https_proxy=http://127.0.0.1:8082, then follow a redirect from http://127.0.0.1:8000/redir to https://127.0.0.1:8443/final; proxy B will receive Proxy-Authorization.
Read the reasoning
The reproduction steps describe a concrete scenario, but the code implementing the described flow (proxy env var parsing, redirect following, proxy re-selection, credential carry-over) is not in the provided source.
The disclosure crosses a real proxy trust boundary and can expose reusable proxy secrets before any authentication challenge from the second proxy.
Read the reasoning
This is an impact assessment dependent on C1-C4 being true. Since the underlying mechanism cannot be verified from the provided code, the impact claim also cannot be verified.
Read the original report (excerpt)
Source code
| 794 | #define CURLPROXY_HTTPS 2L /* HTTPS but stick to HTTP/1 |