CVE-2026-114620 in Authlib
Summary
by MITRE • 10/22/2026
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 request_uri parameter to the abstract get_request_object() 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/authorization_server.py forwards request_uri to get_request_object() before an application-approved retrieval policy accepts the destination. This issue is fixed in version 1.9.0.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/23/2026
The vulnerability identified in Authlib prior to version 1.9.0 represents a critical logic flaw within the implementation of RFC 9101 JWT Authentication Requests, specifically affecting OAuth and OpenID Connect servers built using this library. The core issue stems from the order of operations during request validation, where the unauthenticated client-controlled parameter known as request_uri is passed to an abstract hook method named get_request_object before any destination or registration policy checks are applied. This architectural decision creates a window for exploitation because the framework assumes that downstream integrations will handle security constraints appropriately, but fails to enforce these constraints at the library level itself. The documentation and default examples often demonstrate this hook performing unrestricted HTTP fetches, which sets a dangerous precedent for developers who may not implement additional safeguards in their custom logic.
From a technical perspective, the flaw allows a remote attacker with knowledge of a valid public client identifier to manipulate the authorization server into making outbound network requests to arbitrary destinations. Since the get_request_object() hook is invoked before policy enforcement, an attacker can supply maliciously crafted request URIs that point to internal services, link-local addresses, or other unintended endpoints within the deployment environment. The vulnerability relies on side-channel information leakage; by observing different error responses and timing variations returned by the server, an attacker can distinguish between successful fetches and failed ones. This capability effectively transforms the authorization server into a blind HTTP server-side request forgery proxy, enabling reconnaissance of internal network topologies or access to sensitive backend services that are not directly exposed to the public internet.
The operational impact of this vulnerability is significant for any deployment where the integrator has implemented the get_request_object hook as an unrestricted outbound fetcher without implementing strict allowlists or destination controls. Such configurations expose the organization to server-side request forgery attacks, which can lead to unauthorized data access, internal network mapping, and potential pivoting into more secure zones of the infrastructure. However, it is important to note that deployments where custom hooks already apply rigorous security measures—such as domain whitelisting, destination validation against a known list, and retrieval limits—are not affected by this specific flaw. The vulnerability exists primarily in environments relying on default or loosely configured implementations that trust client-supplied URIs without sufficient pre-validation at the framework level.
To mitigate this risk, organizations must ensure they are running Authlib version 1.9.0 or later, where the logic has been corrected to apply destination and registration policies before invoking the request retrieval hook. For those unable to upgrade immediately, a temporary mitigation involves modifying custom implementations of get_request_object to strictly validate the request_uri against an allowlist of permitted domains and protocols before attempting any network fetches. Additionally, implementing egress filtering at the network level can restrict outbound connections from the authorization server to only known external endpoints, thereby reducing the blast radius even if the application logic is flawed. This incident highlights the importance of defense-in-depth strategies in authentication libraries, where framework-level checks should complement rather than solely rely on developer-implemented security controls.
This vulnerability aligns with CWE-20 Improper Input Validation and CWE-918 Server-Side Request Forgery as defined by industry standards. In terms of attack tactics, it maps to ATT&CK technique T1571 which involves non-standard ports or protocols for command and control, although here the focus is on using standard HTTP/HTTPS for unauthorized internal access. The exploitation vector requires network connectivity to the authentication endpoint and knowledge of a valid client identifier, classifying it as an attack that can be conducted remotely with low complexity but requiring specific environmental configurations to succeed fully. Security teams should audit their OAuth2/OpenID Connect implementations immediately to verify whether they are susceptible based on their version number and custom hook configurations.