CVE-2026-65627: Decompression bomb via unbounded zlib:inflate in jose_jwe_zip:uncompress/2

Q: Which deployments are realistically exposed?

Deployments using jose versions from 1.0.0 before 1.11.13 are affected if they decrypt attacker-supplied JWE tokens. The vulnerable path is triggered by JWEs carrying the optional zip: DEF header.

Q: What does an attacker need to exploit this?

For common asymmetric key-management algorithms such as RSA-OAEP and ECDH-ES, the attacker needs only the recipient's public key to construct a malicious token. No authentication or secret material is required.

Q: Does application-level payload validation prevent exploitation?

No. Decompression occurs automatically in jose_jwe:block_decrypt/2, before the recipient can inspect or reject the decrypted payload, so post-decryption validation does not prevent the memory exhaustion.

Q: How can we determine whether our application is affected?

Check whether the application uses jose before version 1.11.13 and calls jose_jwe:block_decrypt/2 or JOSE.JWE.block_decrypt/2 on untrusted JWE input. Tokens using zip: DEF reach the vulnerable decompression function.

Published Oct 26, 2026

Updated

Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in potatosalad jose (erlang-jose) allows a remote attacker to exhaust a node's memory with a small crafted JWE token.

The josejwezip:uncompress/2 function in src/jwe/josejwezip.erl decompresses the DEFLATE-compressed plaintext of a JWE that carries the optional zip: DEF header by calling zlib:inflate/2 on the entire attacker-controlled stream, with no bound on the output size or the inflation ratio. Raw DEFLATE reaches ratios around 1000:1 on highly repetitive input, so a few-kilobyte token inflates to hundreds of megabytes or gigabytes in a single call.

Decompression runs automatically during decryption through josejwe:blockdecrypt/2 (JOSE.JWE.blockdecrypt/2 in Elixir), before the recipient can inspect or reject the payload. With the common asymmetric key-management algorithms (RSA-OAEP, ECDH-ES) an attacker needs only the recipient's public key to craft such a token, so no authentication or secret material is required. A single small token can exhaust the node's memory and crash the BEAM, denying service to all users.

This issue affects jose: from 1.0.0 before 1.11.13.

Affected Software

1 affected component

potatosalad jose>=1.0.0<1.11.13

Event History

Oct 26, 2026

CVE Published

via MITRE·07:53 PM

Data Sourced

via MITRE·07:53 PM

DescriptionWeakness

Frequently Asked Questions

Which deployments are realistically exposed?

Deployments using jose versions from 1.0.0 before 1.11.13 are affected if they decrypt attacker-supplied JWE tokens. The vulnerable path is triggered by JWEs carrying the optional zip: DEF header.

What does an attacker need to exploit this?

For common asymmetric key-management algorithms such as RSA-OAEP and ECDH-ES, the attacker needs only the recipient's public key to construct a malicious token. No authentication or secret material is required.

Does application-level payload validation prevent exploitation?

No. Decompression occurs automatically in jose_jwe:block_decrypt/2, before the recipient can inspect or reject the decrypted payload, so post-decryption validation does not prevent the memory exhaustion.

How can we determine whether our application is affected?

Check whether the application uses jose before version 1.11.13 and calls jose_jwe:block_decrypt/2 or JOSE.JWE.block_decrypt/2 on untrusted JWE input. Tokens using zip: DEF reach the vulnerable decompression function.

CVE-2026-65627: Decompression bomb via unbounded zlib:inflate in jose_jwe_zip:uncompress/2

Affected Software

Event History

Frequently Asked Questions

Which deployments are realistically exposed?

What does an attacker need to exploit this?

Does application-level payload validation prevent exploitation?

How can we determine whether our application is affected?

Company

Resources

Contact

Frequently Asked Questions

Which deployments are realistically exposed?

What does an attacker need to exploit this?

Does application-level payload validation prevent exploitation?

How can we determine whether our application is affected?