CVE-2026-94266 in curl
Summary
by MITRE • 10/21/2026
libcurl could accidentally return a URL for `curl_easy_getinfo()`'s `CURLINFO_EFFECTIVE_URL` option containing credentials, even though neither the URL provided to libcurl nor the redirected URL did.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/21/2026
The vulnerability in question represents a significant information disclosure flaw within the widely used libcurl library, specifically affecting how it handles Uniform Resource Locators during HTTP redirection sequences. This issue centers on the CURLINFO_EFFECTIVE_URL option of the curl_easy_getinfo function, which is designed to return the final URL that was actually fetched after any redirects have been processed. Under normal operational circumstances, this field should reflect only the host and path components necessary for identifying the resource location, stripping away sensitive authentication data such as usernames and passwords embedded in the URI scheme. However, due to a logic error in how libcurl constructs or updates its internal representation of the effective URL during certain redirect scenarios, it inadvertently retains credential information that was not present in either the original request URL nor the final destination URL provided by the server.
From a technical perspective, this flaw arises from an improper handling of URI components when following redirects. When libcurl processes a redirection response, typically indicated by HTTP status codes such as 301 Moved Permanently or 302 Found, it updates its internal state to reflect the new target location. The bug occurs because the library fails to properly sanitize or reconstruct the effective URL string in specific edge cases where credentials might be implicitly carried over from previous connection states or incorrectly merged with the redirect path. This results in a situation where an application querying CURLINFO_EFFECTIVE_URL receives a URI that includes plaintext username and password fields, even though these credentials were never explicitly sent to the final server nor present in the initial request target.
The operational impact of this vulnerability is primarily related to confidentiality and data leakage. Applications relying on libcurl may inadvertently log or transmit sensitive authentication details if they utilize CURLINFO_EFFECTIVE_URL for debugging, logging, or analytics purposes without realizing that it contains credentials. This exposure can lead to unauthorized access if the logged URLs are stored in insecure locations such as web server logs, application debug files, or third-party monitoring services. Furthermore, since libcurl is a foundational component used by numerous high-profile applications and systems including curl itself, Git, Wget, and various enterprise software suites, the scope of potential exposure is broad. Attackers with access to log files or memory dumps could extract these credentials to compromise user accounts or internal services that rely on HTTP Basic Authentication or similar mechanisms embedded in URLs.
This vulnerability aligns with CWE-209, which describes the generation of an error message that includes sensitive information, and more specifically CWE-532, concerning information exposure through log files. In terms of adversarial tactics, this flaw facilitates reconnaissance activities categorized under ATT&CK technique T1078, Valid Accounts, as it allows attackers to harvest valid credentials without needing to exploit a separate authentication bypass vulnerability. It also relates to ATT&CK tactic TA0006, Credential Access, by providing an indirect method for stealing user credentials through side-channel information leakage rather than direct exploitation of the authentication protocol itself.
Mitigation strategies must focus on both immediate patching and long-term defensive coding practices. The primary remediation is to upgrade libcurl to a version that includes the fix for this specific logic error in URL construction during redirects. Developers should also audit their codebases to ensure that CURLINFO_EFFECTIVE_URL is not used as a source of truth for logging or transmitting URLs without additional sanitization. Implementing strict input validation and output encoding when handling URIs can prevent accidental leakage even if similar flaws exist in underlying libraries. Additionally, organizations should enforce policies that discourage embedding credentials directly within URL strings, favoring header-based authentication methods like HTTP Authorization headers which are less prone to such logging leaks. Regular security audits of dependency usage patterns will help identify other potential vectors for information disclosure related to URI handling and credential management.