GHSA-jj7h-c3hg-m23x: Low severity pip/authlib vulnerability
Summary authlib.common.security.issecuretransport() is used throughout Authlib to enforce the OAuth 2.0 / OIDC requirement that endpoint and redirect URIs use TLS, with an RFC 8252 §7.3 exemption for loopback http:// URIs. The check is implemented as a textual str.startswith prefix match, so a URL such as http://localhost:80@evil.example/cb — whose actual host is evil.example and whose scheme is plain http — is accepted as "secure". An attacker who can supply a URL to any of the sinks that rely on this check (OIDC RP-Initiated Logout dynamic client registration, RFC 8414 authorization-server metadata validation, error-redirect rendering) can smuggle a cleartext non-loopback URL past the TLS-required guard. This is a defense-in-depth / spec-conformance failure; severity is low.
Details Affected versions: authlib >= 0.13, <= 1.7.2 (all releases containing the loopback prefix exemption; verified against 1.7.2, the current latest)
The vulnerable function, from authlib/common/security.py at v1.7.2:
python 13 def issecuretransport(uri): 14 """Check if the uri is over ssl.""" 15 if os.getenv("AUTHLIBINSECURETRANSPORT"): 16 return True 17 18 uri = uri.lower() 19 return uri.startswith( 20 ("https://", "http://localhost:", "http://127.0.0.1:", "http://[::1]:") 21 )
Per RFC 3986 §3.2 the authority component of a URI is [ userinfo "@" ] host [ ":" port ]. The URL http://localhost:80@evil.example/cb therefore has userinfo localhost:80 and host evil.example. Because the check is a raw prefix match against the full URL string, the http://localhost: prefix matches the userinfo portion and the function returns True even though the scheme is http and the host is an arbitrary external name. The trailing : in each allow-list entry — presumably intended to force a host:port shape and reject http://localhost.evil.com — is also satisfied by the user:password separator inside userinfo, so http://localhost:@evil.example/ matches too. The same construction works against all three loopback prefixes (http://127.0.0.1:...@evil.example/, http://[::1]:...@evil.example/).
issecuretransport() is consumed at the following locations in v1.7.2, none of which independently reject URLs containing a userinfo component:
- authlib/oidc/rpinitiated/registration.py:50-57 — validation of postlogoutredirecturis during OIDC dynamic client registration for public clients (tokenendpointauthmethod == "none"). The preceding isvalidurl() check (authlib/common/urls.py:142-146) only requires parsed.scheme and parsed.hostname and does not reject userinfo, so the crafted URL passes both guards. A public client can therefore register http://localhost:80@attacker.example/cb as a post-logout redirect target; the OpenID Provider will later 302 the end-user's browser to that cleartext non-loopback URL (carrying state). - authlib/oauth2/rfc8414/models.py:61,75,100,115,123,248,284 — validation of issuer, authorizationendpoint, tokenendpoint, jwksuri, registrationendpoint, revocationendpoint, introspectionendpoint in Authorization Server Metadata / OIDC Discovery documents. A relying party using AuthorizationServerMetadata.validate() would accept endpoint values of this form as satisfying the "MUST use https" requirement when they do not. - authlib/oidc/rpinitiated/discovery.py:12 — validation of endsessionendpoint in provider metadata. - authlib/oauth2/rfc6749/errors.py:64 and authlib/oauth1/rfc5849/errors.py:33 — governs how redirecturi is rendered in error bodies (cosmetic).
The http://localhost: prefix was introduced in commit 0225c86b (first released in v0.13); http://127.0.0.1: and http://[::1]: were added later in the 1.6.x line. All variants share the same prefix-match weakness.
PoC Against the current latest release (1.7.2):
sh python3 -m venv venv ./venv/bin/pip install 'authlib==1.7.2' ./venv/bin/python poc.py
poc.py:
python #!/usr/bin/env python3 """ issecuretransport() must return True only for https:// URLs, or http:// URLs whose host is a loopback address (localhost / 127.0.0.1 / ::1).
Bypass: http://localhost:80@evil.example/cb has host 'evil.example' (userinfo = 'localhost:80') per RFC 3986, but matches the prefix 'http://localhost:' and is therefore accepted as secure. """ from urllib.parse import urlparse from authlib.common.security import issecuretransport
cases = [ "http://localhost:80@evil.example/cb", "http://127.0.0.1:80@evil.example/cb", "http://localhost:@evil.example/cb", ]
vulnerable = False for url in cases: parsed = urlparse(url) ok = issecuretransport(url) print(f"issecuretransport({url!r}) = {ok} " f"[actual host = {parsed.hostname!r}, scheme = {parsed.scheme!r}]") if ok and parsed.hostname not in ("localhost", "127.0.0.1", "::1") and parsed.scheme != "https": vulnerable = True
if vulnerable: print("\nVULNERABLE: issecuretransport() returned True for a plain-HTTP " "URL whose host is NOT a loopback address.") else: print("\nNOT VULNERABLE")
assert vulnerable, "expected bypass not observed"
Expected output:
issecuretransport('http://localhost:80@evil.example/cb') = True [actual host = 'evil.example', scheme = 'http'] issecuretransport('http://127.0.0.1:80@evil.example/cb') = True [actual host = 'evil.example', scheme = 'http'] issecuretransport('http://localhost:@evil.example/cb') = True [actual host = 'evil.example', scheme = 'http']
VULNERABLE: issecuretransport() returned True for a plain-HTTP URL whose host is NOT a loopback address.
Impact Deployments are affected if they rely on issecuretransport() — directly or via the Authlib call sites listed above — to reject cleartext non-loopback URLs supplied by an external party. The most realistic path is an OpenID Provider that enables OIDC dynamic client registration and RP-Initiated Logout: a public client can register a postlogoutredirecturis entry of the form http://localhost:80@attacker.example/…, which the provider will later use as an open-redirect target over plain HTTP. Relying parties that call AuthorizationServerMetadata.validate() on fetched discovery documents are also affected, though exploiting that sink requires the attacker to influence the metadata document. This does not bypass the OAuth 2.0 redirect-URI exact-match registration check and does not by itself yield authentication bypass or token theft; it defeats a TLS-required hardening check.
Suggested fix: Parse the URI with urllib.parse.urlsplit() and return True only if scheme == "https", or scheme == "http" and hostname in {"localhost", "127.0.0.1", "::1"}; additionally reject any URI whose parsed username/password is non-empty at these validation sites.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/authlibto a version that resolves this vulnerability.Fixed in 1.8.0 - Compensating control
Fix authlib.common.security.is_secure_transport() to parse URIs with urllib.parse.urlsplit() and return True only when scheme == "https", or when scheme == "http" and hostname is one of "localhost", "127.0.0.1", or "::1"; reject any URI whose parsed username or password is non-empty at the listed validation sites.
Event History
Frequently Asked Questions
Which Authlib versions are affected?
Authlib versions 0.13 through 1.7.2 are affected. The issue applies to releases containing the loopback HTTP prefix exemption in is_secure_transport().
What must an attacker be able to control to exploit this?
An attacker must be able to supply a URL to a feature that relies on is_secure_transport() for TLS enforcement. Identified sinks include OIDC RP-Initiated Logout dynamic client registration, RFC 8414 authorization-server metadata validation, and error-redirect rendering.
How can I identify a malicious URL that may bypass the check?
Look for HTTP URLs that begin with an allowed localhost-style prefix but use userinfo syntax to place a different host after an @ character. For example, http://localhost:80@evil.example/cb has evil.example as its actual host and is not a loopback URL.
What can be done if an update is not immediately available?
Validate redirect and endpoint URLs using parsed URI components rather than string prefixes. Permit plain HTTP only when the parsed host is genuinely a loopback host; require TLS for non-loopback destinations.
Does AUTHLIB_INSECURE_TRANSPORT affect the transport check?
Yes. When AUTHLIB_INSECURE_TRANSPORT is set, is_secure_transport() returns true, disabling its normal secure-transport validation.