CVE-2026-86414 in libcurl
Summary
by MITRE • 10/20/2026
An HTTP proxy can trick libcurl into sending the origin's credentials (Basic password, or a Negotiate/Kerberos ticket) to the proxy itself, by answering the `CONNECT` tunnel request with 401 `WWW-Authenticate:` instead of the expected 407 `Proxy-Authenticate:`.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/20/2026
The vulnerability described involves a critical flaw in how libcurl handles authentication challenges during HTTPS CONNECT requests through an HTTP proxy. When establishing a secure connection to a remote server via a proxy, clients typically send a CONNECT request to tunnel TCP traffic over the HTTP protocol. In standard operation, if the proxy requires authentication, it responds with a 407 Proxy Authentication Required status code along with a Proxy-Authenticate header specifying the required method and realm. However, this vulnerability arises when an attacker-controlled or misconfigured intermediate proxy instead returns a 401 Unauthorized response accompanied by a WWW-Authenticate header, which is traditionally used for authenticating directly to origin servers rather than proxies.
Due to libcurl's implementation logic at the time of discovery, the library fails to strictly distinguish between these two distinct authentication challenges in certain contexts. Instead of rejecting the 401 response as invalid for proxy authentication or ignoring it, libcurl interprets the WWW-Authenticate header similarly to a Proxy-Authenticate challenge. Consequently, the client proceeds to construct an Authorization request header using credentials intended for the origin server, such as Basic HTTP passwords or Negotiate/Kerberos tickets, and sends them back to the proxy in response to the 401 error. This behavior effectively bypasses the security boundary between the client and the destination host, allowing the intermediary network element to capture sensitive authentication material that was never meant for it.
The operational impact of this flaw is severe, particularly in environments where users rely on transparent proxies or when connecting through untrusted networks such as public Wi-Fi hotspots, corporate gateways with misconfigured firewalls, or compromised intermediate nodes. If a user authenticates to an origin server using Basic Authentication, the plaintext password can be intercepted by the proxy if it exploits this logic error. For more secure methods like Kerberos or NTLM Negotiate, while the credentials themselves are not immediately readable in plain text, capturing the authentication tokens allows for potential replay attacks or credential theft that could facilitate unauthorized access to internal resources later. This undermines the fundamental trust model of HTTPS tunneling and exposes users to man-in-the-middle style attacks even when using encrypted channels.
From a classification perspective, this issue aligns with CWE-200: Information Exposure, as it leads to the unintended disclosure of sensitive authentication data. It also relates to CWE-346: Origin Error Authentication Bypass, where an attacker exploits differences in how different entities handle authentication challenges. In terms of MITRE ATT&CK frameworks, this vulnerability facilitates Credential Access techniques such as T1059 Command and Scripting Interpreter if combined with other vectors, but primarily it supports T1557 Adversary-in-the-Middle by allowing the interception of credentials during transit. The root cause lies in insufficient validation of HTTP status codes relative to their intended context within the proxy tunneling workflow.
Mitigation strategies require both immediate patching and architectural adjustments. Users should update libcurl to versions where this logic has been corrected to strictly enforce that 401 responses are not processed as proxy authentication challenges unless explicitly configured otherwise, which is generally unsafe anyway. Developers integrating libcurl into applications should ensure they are using the latest stable release and review their configuration settings for any custom handling of HTTP errors. Network administrators must audit their proxy configurations to ensure they correctly return 407 status codes with Proxy-Authenticate headers when authentication is required for CONNECT requests, rather than defaulting to standard web server error responses that might trigger client-side confusion. Additionally, organizations should prioritize the use of certificate-based authentication or token-based systems over Basic Authentication where possible to reduce the risk associated with credential interception in proxy environments.