CVE-2025-62706

What it actually does

Authlib’s JWE decryption path for tokens that set zip=DEF performs unbounded DEFLATE (zlib) inflation. A compact, well-formed ciphertext can expand into tens or hundreds of megabytes in a single decrypt, driving unbounded heap growth and CPU use in the worker that handles the token. Impact is availability-only: no confidentiality or integrity bypass is implied. The condition is reached only when the library actually decrypts a JWE that uses the DEF compression parameter.

Why it matters to the business

Applications that decrypt JWEs with Authlib (login, API gateways, service-to-service tokens) can suffer worker crashes, request timeouts, or full process OOM, interrupting authentication and other token-gated flows. CVSS 6.5 reflects a network-reachable DoS with no privilege required beyond the ability to present a decryptable token. EPSS remains low (~0.0046, +8% over 30 days) and the issue is not in CISA KEV, with no public exploit maturity after ~353 days, so mass opportunistic exploitation is unlikely—but any internet-facing Authlib decrypt path is still an availability risk until patched. Downstream Python services that pin older Authlib from git or PyPI inherit the same outage potential.

How an attack unfolds

An attacker who can cause the victim to decrypt a JWE they created (typically by encrypting to a published recipient public key, or by feeding tokens into any endpoint that decrypts client-supplied JWEs) includes zip=DEF in the protected header and a highly compressible plaintext. Authlib decrypts the JWE then inflates the payload with no output-size cap. Memory and CPU spike on that worker; repeated or concurrent submissions can exhaust the process or host and deny service to legitimate clients. Named threat-actor or ransomware use is not reported.

How to fix it

Upgrade lepture/authlib to a build that includes git commit 9ec42561cd1a81b518598d252f8adbcf446f7419 (the published fix for unbounded zip=DEF decompression). Rebuild and redeploy all services that vendor or pin Authlib. Until the upgrade is live: reject JWEs whose protected header contains zip=DEF; avoid decrypting untrusted JWEs; apply process memory limits, request size limits, and per-client rate limits on decrypt endpoints; and pin Authlib in lockfiles so older git revisions cannot be reintroduced.

How to confirm the fix worked

Confirm installed Authlib contains commit 9ec42561cd1a81b518598d252f8adbcf446f7419 (package metadata, git describe, or lockfile hash). Search application and image inventories for Authlib checkouts or wheels older than that commit. Code-review JWE decrypt call sites and confirm zip=DEF is either rejected or decompressed with a strict output bound. In staging, send ordinary (non-bomb) JWEs with and without zip=DEF and verify legitimate tokens still decrypt while oversized inflation is refused or capped. Dependency scanners and SBOMs should show no remaining vulnerable Authlib revisions.

Typical attack path

1. Discover an application or API that decrypts JWEs with Authlib (JOSE/JWE login, callback, or service-token endpoints).
2. Obtain or reuse a key the recipient will accept (commonly the server’s JWE public key, or any key already trusted for decryption).
3. Create a small JWE whose protected header sets zip=DEF and whose compressed plaintext expands dramatically on inflate.
4. Submit one or many such tokens to the decrypt path (HTTP body, Authorization header, or callback parameter).
5. The worker decrypts then performs unbounded DEFLATE, consuming large amounts of RAM and CPU.
6. Repeat or parallelize until workers OOM, restart, or stop serving legitimate traffic.

How to detect it

This is an availability attack with no persistence; look for evidence of decrypt-time inflation rather than a planted implant. Review application and reverse-proxy logs around JWE/JWT decrypt endpoints for bursts of similar compact tokens, 5xx spikes, worker timeouts, and Python process restarts. On hosts, correlate OOM-killer events and sudden RSS growth in Python workers that import authlib with timestamps of token decrypts. Decode compact JWE first segments (protected headers) from access logs or captured bodies and look for zip set to DEF. Application exception logs may show MemoryError, zlib/deflate errors, or stack frames in authlib.jose JWE decrypt/decompress. There are no named APT campaigns; treat clustered OOM on Authlib workers after unusual JWE traffic as the primary hunting hypothesis.

• "zip":"DEF"
• "zip": "DEF"
• zip=DEF
• authlib.jose
• jose.errors
• MemoryError
• zlib.error
• deflate
• inflate
• python.*oom
• Killed process .*python

What your security team should do

• Patch Authlib to commit 9ec42561cd1a81b518598d252f8adbcf446f7419 (or a release that includes it) on every service that decrypts JWEs, and lock the version.
• Inventory all JWE decrypt entry points and, as a temporary control, refuse tokens with zip=DEF until the library is upgraded.
• Enforce worker memory ceilings, request-body limits, and rate limits on token-decrypt endpoints so a single inflate cannot take down the host.
• Add SBOM/lockfile checks so older Authlib git pins cannot return via transitive Python dependencies.
• Prioritize internet-facing auth and API gateways; internal-only decryptors can follow on a short SLA given low EPSS and no KEV listing.