CVE-2025-61920

What it actually does

Authlib’s JOSE stack (JWS/JWT compact serialization) does not bound the length of the base64url-encoded header or signature segments before decode and parse. On verification it fully base64url-decodes and then JSON/crypto-processes those segments, so a single unauthenticated token with an enormous header or signature can allocate multi-gigabyte RSS and burn seconds of CPU before the token is rejected. Confidentiality and integrity are not affected; the impact is availability (resource exhaustion / denial of service) on any process that calls Authlib verification. Versions at or below 1.6.3 are affected; later trees that enforce ~256 KB header/signature limits are not.

Why it matters to the business

Any internet-facing or internally reachable service that verifies JWTs or JWS with vulnerable Authlib (common in Python OAuth2/OIDC login, API gateways, and service-to-service auth) can be taken down by unauthenticated requests, interrupting sign-in, APIs, and dependent business workflows. One oversized token can pin workers and memory; concurrent submissions can exhaust capacity. CVSS 7.5 (network, low complexity, no privileges, availability-high). Not listed in CISA KEV, not tied to ransomware campaigns, exploit maturity reported as none, and EPSS remains low (~0.006, slight 30-day rise). Still treat as a high-priority availability defect wherever Authlib verifies untrusted tokens, especially given how widely the library is reused in Python identity stacks. The issue has been public for many months, so remaining unpatched estates are overdue.

How an attack unfolds

An unauthenticated network attacker crafts a compact JWS/JWT whose header or signature segment is far larger than any legitimate token, then submits it to an endpoint that invokes Authlib JOSE verification (Authorization bearer token, form/body assertion, or similar). Vulnerable Authlib (≤ 1.6.3) decodes and parses the entire segment before rejecting it, driving CPU and RAM to hostile levels (public write-ups describe on the order of multi-GB RSS and multi-second CPU for a hundreds-of-megabytes header). The request fails cryptographically but the damage is the resource spike. Repeating or parallelizing the same pattern saturates workers, triggering timeouts, OOM kills, and service outage. No credentials or user interaction are required. There is no public association with named APT groups or ransomware crews for this CVE; risk is opportunistic DoS rather than a known targeted campaign.

How to fix it

Upgrade Authlib off the vulnerable line (≤ 1.6.3) to a release that enforces bounded JWS/JWT header and signature sizes (256 KB limits in the patched snapshots). For source/git consumers, the fix is in commit 9ec42561cd1a81b518598d252f8adbcf446f7419; prefer a tagged release that includes that change rather than pinning an arbitrary SHA in production. Rebuild and redeploy all services that vendor or depend on authlib.jose. As defense in depth, cap inbound HTTP body and header sizes at the reverse proxy or application server to well below the point where decode would be expensive, reject compact tokens whose any segment exceeds a small application-level limit (kilobytes, not megabytes) before calling Authlib, and isolate JWT verification in memory- and CPU-limited workers so a single request cannot take down the whole process. Ignore unrelated ntfs-3g Debian package entries in mixed inventory feeds unless a separate advisory actually applies to those packages.

How to confirm the fix worked

Confirm deployed Authlib is newer than 1.6.3 and/or contains the 256 KB header/signature limits (dependency lockfiles, pip show/poetry/uv freeze, container SBOMs, and the installed authlib package version). Static check: search application code for jwt.decode / jose JWS verify call sites and ensure a size gate exists in front of them. Dynamically, send only modest oversized-but-safe tokens (for example just over a legitimate max but far under proxy limits) and confirm they are rejected cheaply without a memory spike; do not load-test with hundreds-of-megabytes tokens in shared environments. After upgrade, verification of a normal-sized token should still succeed, and attempts with huge segments should fail fast with a size/format error rather than multi-second CPU and gigabyte RSS. Track RSS and CPU of JWT-handling workers under synthetic auth traffic.

Typical attack path

1. Identify an application or API that verifies JWS/JWT with Authlib (login, OAuth/OIDC, or token-protected APIs).
2. Send an unauthenticated request carrying a compact JWS/JWT with an abnormally large header or signature segment.
3. Authlib fully decodes and parses the oversized segment, consuming large CPU and memory before rejection.
4. Repeat or parallelize submissions to exhaust workers, memory, or request queues.
5. Service availability degrades or collapses (timeouts, 5xx, process restarts) without any token being accepted as valid.

How to detect it

This is an availability attack, not a persistence implant: look for the attempt itself rather than leftover malware. Hunt HTTP access, API gateway, and WAF logs for unauthenticated requests with extremely large Authorization Bearer values or request bodies containing compact JWS/JWT (three base64url segments separated by dots) where the first or last segment is orders of magnitude larger than normal tokens (typical JWTs are a few kilobytes). Correlate those requests with Python process RSS/CPU spikes, worker timeouts, OOM killer events, and 5xx bursts on authentication or token-introspection routes. Application logs may show Authlib/JOSE verification errors, JSON decode failures, or long request durations immediately after a huge token. Packet captures or proxy logs showing a single header or body of tens to hundreds of megabytes targeting JWT endpoints are highly suspicious. There are no public named-actor TTPs for this CVE; treat clusters of oversized-token requests from one source as opportunistic DoS. Historical window: public since 2025-10-10; review logs from first exposure of the vulnerable service, not only from patch day.

• Authorization: Bearer [A-Za-z0-9_-]{100000,}
• eyJ[A-Za-z0-9_-]{10000,}\.
• authlib.jose
• jose.errors
• ModuleNotFoundError: authlib (noise; prefer version and call-stack hits in jwt/jws verify)
• python.*authlib.*(jwt|jws|jose)
• OOM-killed.*python
• request body size > 1048576 on /token|/oauth|/login|/jwks|/introspect|/authorize
• duration_ms > 5000 AND status in 4xx/5xx AND path matches token or auth endpoints

What your security team should do

• Patch or upgrade Authlib past 1.6.3 (git fix 9ec42561cd1a81b518598d252f8adbcf446f7419 / releases with 256 KB JOSE segment limits) on every service that verifies JWS/JWT, as a priority availability fix even though this CVE is not KEV and EPSS is low.
• Inventory Python apps and lockfiles for authlib; treat any remaining ≤1.6.3 as exposed if they verify untrusted tokens.
• Enforce reverse-proxy and app-level limits on Authorization header, request body, and JWT compact-segment length before JOSE parse.
• Run JWT verification in resource-limited workers and add memory/CPU alerts on those processes.
• Do not run destructive multi-hundred-megabyte token tests against production; use version checks and bounded negative tests instead.
• Triage mixed scanner results that list unrelated products (for example ntfs-3g) separately so Authlib upgrades are not delayed.