Source: python-authlib Version: 1.7.2-2 X-Debbugs-CC: [email protected] Severity: important Tags: security upstream
Hi, The following vulnerabilities were published for python-authlib. CVE-2026-104056[0]: | Authlib version 1.7.2 and below contains a vulnerability where | discovery JSON metadata is cached without validation or issuer- | origin binding. This allows a poisoned discovery response to replace | all endpoint values with attacker-controlled values rather than | endpoint URLs that share the origin of the configured server | metadata URL. CVE-2026-114614[1]: | 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. CVE-2026-114615[2]: | Authlib is a Python library which builds OAuth and OpenID Connect | servers. From 1.3.1 until 1.9.0, OctKey.import_key() checks | asymmetric-key markers only at byte zero while Authlib's PEM loaders | accept leading whitespace, comments, or a byte-order mark. In | deployments that use the documented mixed algorithm registry and | already configure verification with PEM or certificate bytes | containing such a prefix, an unauthenticated attacker who knows | those same public-key bytes can use them as an HMAC secret and forge | HS256 tokens with arbitrary identity or authorization claims. This | is a bypass of the remediation for CVE-2024-37568. The module-level | jwt object reaches OctKey.import_key() in | authlib/jose/rfc7518/oct_key.py, where POSSIBLE_UNSAFE_KEYS fails to | identify prefixed asymmetric key material. This issue is fixed in | version 1.9.0. CVE-2026-114616[3]: | Authlib is a Python library which builds OAuth and OpenID Connect | servers. Prior to 1.9.1, Authlib's OctKey.import_key() and HMAC | signing and verification path accept zero-length key material. If an | application's secret lookup can return an empty string or empty | bytes, a remote attacker can compute the deterministic HS256, HS384, | or HS512 signature for arbitrary token claims and have Authlib treat | the token as authentic. This issue is fixed in version 1.9.1. CVE-2026-114617[4]: | Authlib is a Python library which builds OAuth and OpenID Connect | servers. Prior to 1.9.0, OpenIDMixin.parse_id_token() reads the | nonce_supported decision from the untrusted ID token being validated | and sets the expected nonce to null when that claim is the JSON | boolean false. In implicit and hybrid relying parties, or | applications that directly accept externally supplied ID tokens, an | attacker with a captured validly signed token can bypass the nonce- | to-session binding and replay the victim's token into an attacker- | controlled session. Plain authorization code flow is not affected, | and the token must still pass signature, issuer, and audience | validation. OpenIDMixin.parse_id_token() trusts nonce_supported in | both authlib/integrations/base_client/sync_openid.py and | authlib/integrations/base_client/async_openid.py to disable the | expected nonce. This issue is fixed in version 1.9.0. CVE-2026-114618[5]: | Authlib is a Python library which builds OAuth and OpenID Connect | servers. Prior to 1.9.0, the default RFC 7523 | JWTBearerGrant.get_audiences() returns an empty list, causing | JWTBearerGrant.verify_claims() to require only that an aud claim | exists without matching the current authorization server. An | attacker holding a legitimate assertion for another service can | present it to a server that shares the signing key and uses the | default grant, obtaining an access token across a trust boundary. | Implementations that override get_audiences() with the server's | valid audience identifiers are not affected. This issue is fixed in | version 1.9.0. CVE-2026-114619[6]: | Authlib is a Python library which builds OAuth and OpenID Connect | servers. Prior to 1.9.0, | OpenIDImplicitGrant.validate_authorization_request() checks the | client-controlled raw request.payload.scope for openid after the | parent grant has filtered allowed scopes into request.scope. A | registered client permitted an ID token response type but not the | openid scope can add openid to the request, obtain user consent, and | receive a signed ID token containing the user's subject and allowed | profile claims. Authorization code flow and deployments that allow | openid for every client permitted an ID token response are not | affected. In authlib/oidc/core/grants/implicit.py, | OpenIDImplicitGrant.validate_authorization_request() checks | request.payload.scope instead of the filtered request.scope. This | issue is fixed in version 1.9.0. CVE-2026-114620[7]: | Authlib is a Python library which builds OAuth and OpenID Connect | servers. Prior to 1.9.0, Authlib's RFC 9101 JWTAuthenticationRequest | passes the unauthenticated, client-controlled request_uri parameter | to the abstract get_request_object() hook before applying a | destination or registration policy; the hook itself performs no | network request, while the documentation demonstrates an | unrestricted HTTP fetch. In deployments whose integrator implements | that hook as an unrestricted outbound fetch, a remote attacker who | knows a valid public client identifier can make the authorization | server request internal, link-local, or otherwise unintended URLs | and can distinguish fetch outcomes through different error responses | and timing. Deployments whose custom hook already applies a secure | allowlist, destination controls, and retrieval limits are not | affected. The JWTAuthenticationRequest implementation in | authlib/oauth2/rfc9101/authorization_server.py forwards request_uri | to get_request_object() before an application-approved retrieval | policy accepts the destination. This issue is fixed in version | 1.9.0. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2026-104056 https://www.cve.org/CVERecord?id=CVE-2026-104056 [1] https://security-tracker.debian.org/tracker/CVE-2026-114614 https://www.cve.org/CVERecord?id=CVE-2026-114614 [2] https://security-tracker.debian.org/tracker/CVE-2026-114615 https://www.cve.org/CVERecord?id=CVE-2026-114615 [3] https://security-tracker.debian.org/tracker/CVE-2026-114616 https://www.cve.org/CVERecord?id=CVE-2026-114616 [4] https://security-tracker.debian.org/tracker/CVE-2026-114617 https://www.cve.org/CVERecord?id=CVE-2026-114617 [5] https://security-tracker.debian.org/tracker/CVE-2026-114618 https://www.cve.org/CVERecord?id=CVE-2026-114618 [6] https://security-tracker.debian.org/tracker/CVE-2026-114619 https://www.cve.org/CVERecord?id=CVE-2026-114619 [7] https://security-tracker.debian.org/tracker/CVE-2026-114620 https://www.cve.org/CVERecord?id=CVE-2026-114620 Regards, Salvatore
