CVE-2026-114614 in Authlib
Summary
by MITRE • 10/23/2026
Authlib is a Python library which builds OAuth and OpenID Connect servers. From 0.13 until 1.8.0, authlib.common.security.is_secure_transport() uses a textual prefix comparison for loopback HTTP exemptions, so a URL whose userinfo begins with a loopback host can be accepted even when its parsed host is an external non-loopback system. An external party able to supply a URL to OIDC RP-Initiated Logout registration, authorization-server metadata validation, or another call site can bypass the TLS-required guard and cause cleartext redirection or acceptance of cleartext endpoints. The issue does not bypass redirect URI exact matching and does not by itself forge tokens or authenticate users. The vulnerable authlib.common.security.is_secure_transport() implementation in authlib/common/security.py misinterprets the userinfo component before OIDC RP-Initiated Logout dynamic client registration and other consumers enforce transport security. This issue is fixed in version 1.8.0.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/23/2026
The vulnerability identified within Authlib versions ranging from 0.13 to 1.8.0 stems from a fundamental flaw in the implementation of the is_secure_transport function located in authlib/common/security.py. This library serves as a critical component for building OAuth and OpenID Connect servers, where ensuring secure transport mechanisms is paramount for maintaining the integrity of authentication flows. The specific defect lies in how the function validates whether a given URL utilizes a secure connection protocol such as HTTPS. Instead of performing a rigorous structural analysis that correctly parses the Uniform Resource Identifier according to standard specifications like RFC 3986, the implementation relies on a simplistic textual prefix comparison for loopback HTTP exemptions. This approach fails to account for the hierarchical structure of URIs, specifically ignoring the distinction between different components such as scheme, authority, userinfo, host, and path.
The technical flaw manifests when an attacker constructs a URL where the userinfo component begins with text resembling a loopback hostname, such as localhost or 127.0.0.1. Because the validation logic checks for this prefix within the entire string rather than isolating the actual host field after parsing, it incorrectly classifies the transport as secure and exempt from TLS requirements. Consequently, even if the parsed host is an external non-loopback system accessible over a standard HTTP connection, the application accepts it as valid. This misinterpretation allows for the bypass of security guards that are designed to enforce encrypted communications during sensitive operations like OIDC RP-Initiated Logout dynamic client registration and authorization-server metadata validation.
The operational impact of this vulnerability is significant in environments where external parties can supply URLs for configuration or redirection purposes. An attacker capable of injecting such a malformed URL into the OIDC RP-Initiated Logout process or other relevant call sites can force cleartext redirections or cause the server to accept endpoints that transmit sensitive authentication data over unencrypted channels. This exposure potentially allows for man-in-the-middle attacks where session tokens, authorization codes, or user credentials could be intercepted by malicious actors monitoring network traffic. Although this vulnerability does not bypass redirect URI exact matching logic and cannot directly forge tokens or authenticate users on its own, it undermines the confidentiality guarantees provided by TLS, thereby weakening the overall security posture of the identity provider infrastructure.
From a classification perspective, this issue aligns with CWE-20 Improper Input Validation, as the application fails to properly validate input data before using it in security-critical decisions. It also relates to CWE-319 Cleartext Transmission of Sensitive Information, since the flaw leads to the potential transmission of sensitive authentication materials over unencrypted connections. In terms of MITRE ATT&CK mapping, this vulnerability facilitates techniques associated with Credential Access and Defense Evasion by allowing attackers to intercept credentials during transit if they can manipulate the registration or redirection parameters. The lack of strict parsing allows for evasion of transport security controls that are otherwise enforced at higher levels of the application logic.
To mitigate this risk, organizations utilizing Authlib must upgrade immediately to version 1.8.0 or later, where the is_secure_transport function has been corrected to properly parse URLs and validate the host component independently of other fields like userinfo. For systems unable to upgrade instantly, administrators should implement strict input validation at the application layer to reject any URL containing loopback-like strings in non-host positions before they reach Authlib functions. Additionally, enforcing HTTPS-only policies at the reverse proxy or load balancer level can provide an additional layer of defense by ensuring that all traffic is encrypted regardless of how the backend application interprets URLs. Regular security audits and code reviews focusing on URI parsing logic are recommended to prevent similar vulnerabilities in future development cycles.