Live › vulnerability › CVE-2026-114618
Go to dashboardBefore version 1.9.0, Authlib's default RFC 7523 JWT bearer grant only checks that an assertion has an aud claim, without matching it to the current server. An attacker holding a valid assertion issued for another service that shares the signing key can use it to obtain an access token here.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Servers built on Authlib that accept RFC 7523 JWT bearer grants with the default grant class and share a signing key with another service. Servers that override get_audiences() with their own audience identifiers are not affected. Teams not using JWTBearerGrant can skip it.
No product ranges from the sources yet.
pip show authlib or pip freeze | grep -i authlibJWTBearerGrant without overriding get_audiences()1.9.0 or laterget_audiences() to return the server's valid audience identifiersEach row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-114618")
NVD data is provided by NIST and is public domain · EPSS scores by FIRST, used with attribution. Posts quoted belong to their authors.