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