CVE-2026-6253

What it actually does

curl/libcurl can incorrectly reuse proxy credentials intended for one proxy when following a redirect to a URL scheme that is configured to use a different proxy. The issue requires a specific configuration: different proxies are assigned for different URL schemes, the first proxy requires authentication, the second proxy does not, and curl follows a redirect from a URL using the first proxy to a URL using the second proxy. In that flow, authentication material such as a Proxy-Authorization header may be sent to the wrong proxy, exposing credentials to an unintended intermediary.

Why it matters to the business

Organizations that use curl or applications built on libcurl with per-scheme proxy settings could unintentionally disclose proxy credentials to another proxy. If those credentials are captured or logged, an attacker may be able to reuse them to access internal or external proxy services, route traffic through trusted infrastructure, bypass egress controls, or create investigation and compliance concerns. The exploitability is currently low, it is not listed in CISA KEV, and no public exploit maturity is reported, but curl is widely embedded in operating systems, appliances, containers, developer tools, and applications, so exposure can be broad and indirect.

How an attack unfolds

An attacker needs to influence a curl/libcurl request that is allowed to follow redirects and that starts with a URL scheme routed through an authenticated proxy. The attacker causes the first request to return an HTTP redirect to a different scheme that the client is configured to access through a second, different proxy that normally does not require credentials. When curl follows the redirect, the vulnerable behavior may cause it to include the first proxy's credentials in the request sent to the second proxy. If the attacker controls, observes, or can access logs from that second proxy, they can capture the leaked Proxy-Authorization value and potentially replay or crack it depending on the authentication mechanism.

How to fix it

Upgrade curl/libcurl through the operating system, container base image, language runtime, appliance, or application vendor when a fixed package is available. Because no fixed versions were provided in the input, track the upstream curl advisory and downstream vendor advisories for the exact corrected release. Rebuild static binaries and container images that embed libcurl; updating the host package alone may not fix bundled copies. As mitigations, disable automatic redirect following for untrusted URLs, avoid using different proxies for different URL schemes where possible, use the same authenticated proxy consistently across schemes, avoid placing high-value credentials in proxy configurations, and restrict access to proxy logs. Rotate proxy credentials if there is evidence that credentials may have been sent to an unintended proxy.

How to confirm the fix worked

Confirm the installed curl and libcurl versions against the fixed version published by the relevant vendor. For applications, verify both dynamically linked and statically bundled libcurl copies. A practical validation test is to configure two test proxies, require authentication on the first proxy, require no authentication on the second, enable redirect following, and serve a redirect from a URL using the first proxy's scheme to a URL using the second proxy's scheme. After remediation, the second proxy must not receive a Proxy-Authorization header or equivalent proxy credential intended for the first proxy. Also review application configuration to confirm redirects are disabled or constrained where they are not required.

Typical attack path

1. Identify or induce use of curl/libcurl in an application, job, script, package manager, or automation workflow that follows redirects.
2. Ensure the client is configured with different proxies for different URL schemes, such as one proxy for HTTP and another proxy for HTTPS.
3. Target a flow where the first proxy requires authentication and the second proxy does not.
4. Return or inject a redirect from the first requested scheme to a second scheme that uses the other proxy.
5. Observe traffic or logs on the second proxy and look for proxy authentication material that should only have been sent to the first proxy.
6. Reuse, decode, relay, or attempt to crack the exposed proxy credentials if the authentication method permits it.

How to detect it

Investigate whether curl/libcurl clients using authenticated proxies followed cross-scheme redirects and sent proxy credentials to a proxy that should not have received them. Useful sources include forward proxy access logs, proxy authentication logs, web gateway logs, packet captures at proxy ingress, EDR network telemetry, application debug logs, curl verbose logs, and CI/CD or automation job output. Focus on time windows where a 30x redirect changed URL scheme, such as HTTP to HTTPS or HTTPS to HTTP, while different proxies were configured for those schemes. On unauthenticated proxies, search for inbound Proxy-Authorization headers, proxy authentication schemes, or base64-looking Basic credentials. If proxy logs record headers, determine whether credentials intended for one proxy appear in requests to another. Also review whether any exposed proxy credentials were later reused from unusual source IPs, at unusual times, or to access destinations outside normal patterns.

• Proxy-Authorization:
• Proxy-Authorization: Basic
• Proxy-Authorization: NTLM
• Proxy-Authorization: Negotiate
• Proxy-Authorization: Digest
• * Proxy auth using Basic
• * Proxy auth using NTLM
• * Proxy auth using Negotiate
• 407 Proxy Authentication Required
• Location: http://
• Location: https://

What your security team should do

• Inventory curl and libcurl usage across servers, containers, CI/CD images, appliances, developer workstations, and applications that statically bundle libcurl.
• Prioritize systems that use authenticated proxies, per-scheme proxy configuration, and automatic redirect following for external or user-controlled URLs.
• Apply vendor updates as soon as fixed packages are available; rebuild containers and statically linked applications that include vulnerable libcurl code.
• Temporarily disable redirect following or standardize proxy configuration for workflows that process untrusted URLs until patching is complete.
• Review proxy logs for unexpected Proxy-Authorization headers on proxies that should not require authentication.
• Rotate proxy credentials if logs or packet captures show credentials were sent to the wrong proxy, or if proxy logs are accessible to untrusted parties.
• Add regression tests for redirect handling in applications that use libcurl with proxy authentication.