CVE-2026-114620: Authlib: Unvalidated request_uri fetch in JWT-secured authorization request (JAR) leading to SSRF
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 requesturi parameter to the abstract getrequestobject() 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/authorizationserver.py forwards requesturi to getrequestobject() before an application-approved retrieval policy accepts the destination. This issue is fixed in version 1.9.0.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Authlibto a version that resolves this vulnerability.Fixed in 1.9.0 - Compensating control
For deployments using a custom get_request_object() hook, enforce an application-approved retrieval policy with a secure destination allowlist, destination controls, and retrieval limits before fetching the client-controlled request_uri.
Event History
Frequently Asked Questions
Which deployments are affected?
Affected deployments use JWT-secured authorization requests and implement get_request_object() as an unrestricted outbound fetch. Deployments whose custom hook already enforces a secure allowlist, destination controls, and retrieval limits are not affected.
What does an attacker need to exploit this?
A remote attacker needs to know a valid public client identifier. They can then supply a client-controlled request_uri that causes an unrestricted implementation to attempt retrieval from internal, link-local, or other unintended destinations.
What can be done if upgrading is not immediately possible?
Apply retrieval policy in the custom get_request_object() implementation before fetching the URI. Use a destination allowlist, block internal and link-local destinations, and impose retrieval limits.
How might exploitation be observable?
An attacker can distinguish fetch outcomes through differing error responses and timing. Review authorization-request failures and timing patterns associated with request_uri retrieval for attempts to reach unintended destinations.
What version contains the fix?
The issue is fixed in Authlib version 1.9.0.