CVE-2026-7168

What it actually does

This flaw causes libcurl to retain and incorrectly reuse an HTTP proxy Digest authentication header when the same easy handle is reused for a subsequent transfer through a different proxy host. If an application first authenticates to one proxy and then changes the proxy target on the same handle, libcurl may send the original `Proxy-Authorization:` header to the new proxy. The primary impact is credential exposure: the second proxy can receive authentication material intended only for the first proxy. Integrity and availability are not directly affected.

Why it matters to the business

Applications, agents, appliances, or services that embed libcurl and dynamically switch between authenticated HTTP proxies could leak proxy authentication credentials to an unintended proxy. In environments where proxy credentials provide access to internal networks, paid egress services, monitoring infrastructure, or partner connectivity, this may enable unauthorized proxy use, policy bypass, or further reconnaissance. The CVSS score is moderate and EPSS is currently low, and it is not listed in CISA KEV, but the issue is still important for products that reuse libcurl handles across different proxy configurations.

How an attack unfolds

An attacker must be positioned to operate, control, or observe the second proxy endpoint, or be able to influence an application into switching from a legitimate Digest-authenticated proxy to an attacker-observed proxy while reusing the same libcurl handle. The application performs a first transfer through `proxyA` using Digest proxy authentication. libcurl constructs and sends a `Proxy-Authorization: Digest ...` header for that proxy. The application then changes the proxy host to `proxyB` for another transfer without discarding or fully resetting the handle. Due to the flaw, libcurl sends the Digest authorization header meant for `proxyA` to `proxyB`. The attacker captures the leaked header from proxy logs or network traffic and may attempt replay, offline analysis, or abuse depending on the Digest parameters, proxy configuration, and credential reuse practices.

How to fix it

Upgrade curl/libcurl to a vendor-provided version that includes the fix when available from the operating system, package manager, appliance vendor, or application vendor. Because no fixed version was provided in the input, track the haxx curl advisory and downstream package advisories for exact corrected releases. As a mitigation, avoid reusing the same libcurl easy handle when changing proxy hosts after Digest proxy authentication; instead create a new handle or fully reset authentication-related state before switching proxies. Avoid sharing proxy credentials across trust boundaries, rotate exposed proxy credentials where leakage is suspected, and prefer least-privilege proxy accounts scoped to only the required destinations. Products embedding libcurl should update the bundled library rather than relying only on system curl command-line versions.

How to confirm the fix worked

Confirm the installed or bundled libcurl version against the vendor advisory once fixed releases are published. Review software bills of materials, package manifests, container images, statically linked binaries, and vendor appliance notices for embedded libcurl. Functionally validate by performing a controlled two-step test: first send a request through a Digest-authenticated proxy, then reuse the same libcurl handle while switching to a second controlled proxy, and verify that the second proxy does not receive a `Proxy-Authorization:` header intended for the first proxy. Also confirm that applications either instantiate a new handle when switching proxies or explicitly clear/reset proxy authentication state.

Typical attack path

1. Identify an application or product that uses affected libcurl versions and supports HTTP proxy Digest authentication.
2. Find a workflow where the application reuses a libcurl handle across transfers while changing the configured proxy host.
3. Gain visibility into, or control over, the second proxy endpoint used after the legitimate authenticated proxy.
4. Trigger or wait for a transfer through the legitimate proxy so libcurl generates a `Proxy-Authorization: Digest` header.
5. Trigger or wait for the proxy configuration to change to the attacker-observed proxy while the same handle is reused.
6. Capture the mistakenly forwarded `Proxy-Authorization:` header at the second proxy.
7. Use the exposed proxy authentication material for unauthorized access attempts, replay where feasible, or further credential analysis.

How to detect it

Look for evidence that proxy credentials were sent to an unexpected proxy endpoint. Useful sources include HTTP proxy access logs, reverse proxy logs if used for proxy chaining, egress gateway logs, packet captures, application debug logs from curl/libcurl integrations, and authentication logs from proxy infrastructure. Search for `Proxy-Authorization: Digest` headers on proxy servers that should not receive Digest credentials, especially immediately after requests from the same client to a different authenticated proxy. Correlate by client IP, application identity, timestamp, destination proxy host, and reused connection workflows. Investigate any proxy logs that record Digest authorization headers for realms or usernames associated with a different proxy. If verbose curl logging is enabled, review whether a request to one proxy includes an authorization header generated for another proxy. Because exploitation may only disclose a header and may not create a successful login event, absence of failed authentication logs does not rule out exposure.

• Proxy-Authorization: Digest
• Proxy-Authenticate: Digest
• Authorization header sent to proxy host mismatch
• Proxy-Authorization header observed on unexpected proxy
• curl verbose log: Proxy-Authorization: Digest
• libcurl debug: Proxy-Authorization: Digest

What your security team should do

• Inventory applications, agents, containers, appliances, and third-party products that use curl/libcurl, especially those with outbound proxy support.
• Prioritize review of systems that use HTTP proxies with Digest authentication and dynamically switch proxy endpoints.
• Track haxx curl and operating system vendor advisories for fixed libcurl packages; patch as soon as corrected versions are available.
• Ask application owners and vendors whether libcurl handles are reused across different proxy hosts after proxy authentication.
• Mitigate immediately in custom code by creating a fresh libcurl handle or fully resetting state before changing proxy hosts.
• Review logs from HTTP proxies for unexpected `Proxy-Authorization: Digest` headers arriving at proxies that should not receive credentials.
• Rotate proxy credentials if there is evidence that authorization headers were sent to an untrusted or unintended proxy.
• Limit proxy credential privileges and enforce network controls so leaked proxy credentials cannot be broadly reused.