erlang-jose CVE-2026-65627

The affected application must decrypt attacker-supplied JWE tokens using jose's JOSE.JWE.block_decrypt/2 (jose_jwe:block_decrypt/2) and must honor the optional zip:"DEF" DEFLATE header - which jose does automatically during decryption, before the recipient can inspect or reject the payload. With asymmetric key management (RSA-OAEP, ECDH-ES) the attacker needs only the recipient's public key and no authentication or secret material. Affected: jose 1.0.0 up to (not including) 1.11.13. LIMITING FACTORS: exploitation requires an exposed code path that decrypts JWEs received from untrusted senders; the attacker must be able to obtain or know the recipient's public key; applications that never accept compressed (zip-header) JWEs, or that reject them before decrypting, are not exposed. Per vendor, 1.11.13 caps inflation at zip_size_maximum (1 MiB default, tunable via the jose zip_size_maximum application env key or jose:zip_size_maximum/1); upgrading is the complete fix, with pre-decrypt rejection of any token whose protected header contains a zip member as the only stated workaround.

This is a remotely triggerable, availability-only denial-of-service (decompression bomb) in erlang-jose. The signals are mixed and point to a real but moderate priority. EPSS is low (0.25%, 16th percentile) and the CVE is NOT in CISA KEV, so there is no evidence of active or widespread exploitation - consistent with a niche-ecosystem library flaw rather than a mass-exploited internet bug. Offsetting that, a full working PoC is included in the GHSA advisory with a VERIFIED log showing 771x amplification (a ~348 KB token inflating to 256 MiB, +459.9 MB measured), so exploitation is demonstrably practical, not theoretical, and requires only the recipient's PUBLIC key with the common asymmetric algorithms (RSA-OAEP, ECDH-ES). The vuln.today decision label is 'this_month' (not act_now/emergency). A key signal conflict must be flagged: the official CVSS 4.0 vector uses AV:L (local), which depresses the 6.9 score, yet the description and PoC clearly show a remotely delivered JWE token crossing a network trust boundary via JOSE.JWE.block_decrypt/2 - a network-vector assessment would score higher (see assessed vectors). Impact is strictly availability (VC:N/VI:N/VA:H / C:N/I:N/A:H): no confidentiality or integrity loss, and the BEAM can be restarted, but a single small token can OOM-kill the node and take down the service for all users, so blast radius per successful request is high. Net: a genuine priority for any Elixir/Erlang service that decrypts JWE tokens from untrusted senders, but not an emergency given low EPSS, no KEV, and DoS-only impact.

An outside attacker who holds only the recipient's public key (as is normal for RSA-OAEP or ECDH-ES) crafts a few-kilobyte JWE carrying the zip:"DEF" header over a highly compressible plaintext such as a long run of zero bytes. When the victim service decrypts the token with JOSE.JWE.block_decrypt/2, jose automatically DEFLATE-inflates the payload via unbounded zlib:inflate/2, expanding a tiny token into hundreds of MB or GB and OOM-killing the BEAM. A working, verified PoC is published in the GHSA advisory (348 KB token → 256 MiB, ~771x amplification), so no special attacker skill or secret material is required.