Authlib CVE-2025-61920

No special configuration is required beyond the target application using Authlib (≤ 1.6.3, and up to < 1.6.5) to verify attacker-supplied JWS/JWT tokens - i.e. any OAuth/OIDC flow, token introspection, or JWT authentication path that calls Authlib's JOSE deserialize_compact / extract_segment routines on untrusted input. Exploitation is remote and unauthenticated (CVSS PR:N, confirmed by vector), needs no user interaction, and succeeds against default configurations because pre-1.6.5 code imposed no size bound. The primary LIMITING factor is deployment of a size guard outside Authlib: if a proxy/WAF or application layer already rejects oversized token inputs (a few KB) before they reach Authlib, or rate-limits the verification endpoint, the amplification is neutralized. Impact is availability-only; no authentication bypass or data disclosure results.

This is a genuine but bounded availability-only risk. All signals align coherently: the CVSS v3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5) describes a remote, low-complexity, unauthenticated attack with no user interaction that impacts only availability (C:N/I:N - no data exposure or integrity loss). The GitHub-issued advisory and commit confirm the root cause (unbounded JOSE header/signature segments, CWE-20) and a vendor fix in 1.6.5, and publicly available exploit code (the GHSA PoC jws_segment_dos_demo.py) lowers the barrier to opportunistic abuse. No EPSS score and no SSVC decision data were provided in the input, and the CVE is NOT listed in CISA KEV, so there is no evidence of active real-world exploitation - the threat is a publicly demonstrated DoS, not confirmed in-the-wild attacks. The practical priority is moderate: exploitation is easy and unauthenticated against any endpoint that verifies attacker-supplied JWS/JWT, but impact is confined to resource exhaustion (the advisory measured ~4 GB RSS and ~9 s CPU for a 500 MB header), and several effective mitigations exist (upstream patch, proxy/WAF input-size limits, rate limiting). Prioritize patching on internet-facing OAuth/OIDC token-verification services; de-prioritize where tokens are already size-capped upstream.

An unauthenticated remote attacker sends a single crafted JWS/JWT to any Authlib-backed OAuth/OIDC verification endpoint, with the base64url header or signature segment inflated to hundreds of megabytes. Authlib fully base64-decodes and parses the oversized buffer before rejecting it, spiking CPU and RAM (~4 GB RSS, ~9 s CPU for a 500 MB header per the advisory) and exhausting service capacity. Publicly available PoC exploit code (jws_segment_dos_demo.py) exists, making the attack trivially reproducible.