CVE-2026-15806 in Python
Summary
by MITRE • 08/18/2026
The HTTPPasswordMgr class in the urllib.request module, along with its subclasses HTTPPasswordMgrWithDefaultRealm and HTTPPasswordMgrWithPriorAuth, did not take the URL scheme into account when matching stored credentials against a requested URL. Credentials added for an https:// URL were also used for requests to the same host over http://, so an attacker able to redirect or downgrade a client to plain HTTP (for example, via an HTTPS-to-HTTP redirect or an on-path position) could capture credentials in cleartext. Credentials added for http:// URLs could likewise be sent over https://.
Credential matching is now scoped by URL scheme. Credentials registered with a URL that includes a scheme are only used for requests with the same scheme. Credentials registered with a bare authority (such as example.com or example.com:8080) continue to match any scheme, preserving compatibility with existing code, including proxy authentication.
Users who cannot upgrade immediately can mitigate by ensuring that applications never make plain http:// requests to hosts for which credentials are registered, for example by not following redirects to http:// URLs.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/18/2026
The vulnerability identified in the urllib.request module's HTTPPasswordMgr class and its subclasses represents a critical flaw in how authentication credentials are scoped against target Uniform Resource Locators. Historically, these classes failed to differentiate between Hypertext Transfer Protocol (HTTP) and Hypertext Transfer Protocol Secure (HTTPS) schemes when matching stored credentials to requested URLs. This oversight meant that credentials registered for an HTTPS endpoint were inadvertently made available for requests directed at the same host but over a plain HTTP connection. Conversely, credentials associated with HTTP endpoints could also be transmitted during secure HTTPS transactions. This lack of scheme-based scoping creates a significant security gap where authentication material intended for encrypted channels is exposed to unencrypted ones, or vice versa, undermining the fundamental purpose of transport layer encryption in protecting credential confidentiality.
The operational impact of this flaw is severe, particularly in environments susceptible to protocol downgrade attacks or HTTPS-to-HTTP redirects. An attacker positioned on the network path who can intercept traffic and force a client to switch from HTTPS to HTTP could capture user credentials transmitted in cleartext. Similarly, if an application follows a redirect that drops down to plain HTTP after initial authentication over HTTPS, those same credentials would be exposed. This behavior violates the principle of least privilege regarding credential scope and exposes users to man-in-the-middle attacks where sensitive data such as usernames and passwords are intercepted without encryption protections. The risk is compounded in scenarios involving proxy authentication or mixed-content environments where different schemes might be used for various resources on the same host, leading to unintended cross-scheme credential leakage.
From a standards perspective, this vulnerability aligns with CWE-259: Use of Hard-coded Passwords and more specifically CWE-798: Use of Hard-coded Credentials in terms of improper scoping, though it is technically an implementation error rather than hardcoding. It also relates to CWE-319: Cleartext Transmission of Sensitive Information because credentials are transmitted over unencrypted channels due to flawed logic. In the context of the MITRE ATT&CK framework, this flaw facilitates Credential Access techniques such as Network Sniffing (T1040) and Man-in-the-Middle Attacks (T1557), allowing adversaries to harvest valid authentication material that should have remained protected by TLS encryption. The failure to enforce scheme-specific boundaries effectively nullifies the security guarantees provided by HTTPS for those specific credentials, creating a persistent attack surface even when secure connections are initially established.
The remediation involves updating the credential matching logic within HTTPPasswordMgr and its subclasses to strictly scope credentials by URL scheme. Credentials registered with a full URL including an explicit scheme such as https:// or http:// will now only be used for requests that match that specific scheme. This change ensures that HTTPS-registered credentials are never sent over plain HTTP connections, thereby preventing cleartext exposure during protocol downgrades. However, to maintain backward compatibility and support legacy applications or proxy configurations that rely on bare authority matching, credentials registered with a bare authority like example.com without an explicit scheme will continue to match any scheme. This hybrid approach balances security improvements with the need for existing codebases to function correctly without immediate breaking changes.
For organizations unable to upgrade their Python environments immediately due to dependency constraints or testing cycles, specific mitigation strategies must be employed. Applications should be configured to never follow redirects that transition from HTTPS to HTTP when credentials are registered for those hosts. Developers can implement custom redirect handlers that reject scheme downgrades or enforce strict TLS usage across all requests to authenticated domains. Additionally, ensuring that the application logic explicitly distinguishes between secure and insecure endpoints before submitting authentication data can reduce exposure. Long-term resolution requires upgrading to a patched version of the library where credential matching is correctly scoped by URL scheme, thereby eliminating the possibility of cleartext transmission due to logical errors in host-based lookup mechanisms.