Authlib EUVD-2026-108522

Exploitation requires ALL of the following: the RFC 9101 JWTAuthenticationRequest (JAR) extension is enabled (support_request_uri defaults to True); the integrator implemented the abstract get_request_object() hook as an unrestricted outbound HTTP fetch (e.g. requests.get(request_uri)) as shown in Authlib's own documentation; and the attacker knows a valid client_id, which is a public, non-secret identifier. The sink is reached before user or client authentication, so per the CVSS PR:N it is unauthenticated. Limiting factors that remove the risk entirely: deployments whose custom get_request_object() already applies a secure allowlist, destination/scheme controls, and retrieval limits are explicitly not affected, and the exfiltration is blind (response bodies are consumed as a JWT and never reflected), so the primitive yields an error/timing oracle for internal discovery rather than direct data exfiltration.

This is a medium-severity, highly conditional SSRF (CVSS 5.4, CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:N) whose real-world risk is substantially lower than the network/unauthenticated metrics suggest, because the flaw only becomes exploitable in deployments whose integrator implemented the abstract get_request_object() hook as an unrestricted outbound fetch - exactly as Authlib's documentation demonstrated. Authlib itself performs no network request, so the signal to weigh is AC:H (the explicit dependence on an unsafe, integrator-supplied hook plus the blind oracle nature) against PR:N (any party knowing a valid, public, non-secret client_id can reach the sink pre-authentication). No EPSS score was provided and the vulnerability is not on CISA KEV, so there is no evidence of active exploitation; the vuln.today priority is 'this_month' rather than act_now/emergency, consistent with a serious-but-not-urgent issue. A public PoC reference exists in the GHSA advisory, but it only demonstrates library-level reachability (the unvalidated URI reaching the hook) and is not verified as a working end-to-end SSRF exploit. Net: a real priority for organizations running RFC 9101 JAR with a documentation-style fetch hook, but a non-issue for deployments that already allowlist destinations - defenders must verify their own hook implementation rather than treat the CVSS alone as the risk.

In an authorization server that enabled RFC 9101 JAR (support_request_uri defaults to True) and implemented get_request_object() as the documented requests.get(request_uri), a remote attacker who knows any valid public client_id sends an unauthenticated /authorize request with request_uri set to http://169.254.169.254/ or an internal host. The server fetches the attacker-chosen URL, and because a falsy fetch raises InvalidRequestUriError while a fetched non-JWT body raises InvalidRequestObjectError, the differing errors plus response timing form an oracle for blind internal host and port discovery. A public PoC reference in the advisory demonstrates the unvalidated URI reaching the hook pre-authentication, though it is not verified as a working network exploit.