CVE-2026-65632

Inefficient Algorithmic Complexity in erlang-jose allows an unauthenticated remote attacker to cause a CPU-exhaustion denial of service by submitting a crafted RSA JSON Web Key. When an application parses an untrusted JWK through the public jose_jwk:from_binary/1 or jose_jwk:from_map/1 API, an RSA private key that supplies d, e, and n but omits all Chinese Remainder Theorem parameters is routed into convert_sfm_to_crt/1, which tries to recover the missing primes by factoring the modulus. When the modulus cannot be split into two factors, the search loop performs a modular exponentiation over the attacker-sized modulus on every iteration and never succeeds.

Observable Timing Discrepancy vulnerability in potatosalad jose allows recovery of a long-term X25519 private key through a timing side channel in the pure-Erlang Curve25519 fallback. The pure-Erlang X25519 implementation performs scalar multiplication over the secret private key using a recursive Montgomery ladder whose execution time depends on the secret scalar, making public entry points (e.g., scalarmult/2, x25519/2) timing-dependent on the private key. This issue affects jose from 1.10.0 before 1.11.13.

The jose library exports password-encrypted private keys in PKCS#8 format using hardcoded PBES2 parameters: PBKDF2-HMAC-SHA256 with 2048 iterations and an 8-byte salt, neither of which can be overridden. These values are far below current guidance, enabling a cheap offline password-cracking attack to recover the private key. The issue affects versions from 1.10.0 before 1.11.13.

jose_jwk:shared_secret/2 (exposed in Elixir as JOSE.JWK.shared_secret/2) derives an ECDH shared secret from two JWKs. Its first function clause only matches when both JWKs carry the same key type (kty) module, and its fallback clause re-invokes itself as shared_secret(from(YourJWK), from(MyJWK)). Because from/1 returns an already-parsed jose_jwk record unchanged, passing two JWKs whose key types differ makes the fallback clause re-enter with identical arguments, producing an unbounded tail-recursive loop that never returns and never crashes.

Improper Handling of Highly Compressed Data (Data Amplification) in potatosalad jose (erlang-jose) allows a remote attacker to exhaust a node's memory with a small crafted JWE token. The jose_jwe_zip:uncompress/2 function decompresses the DEFLATE-compressed plaintext of a JWE carrying the optional zip: DEF header by calling zlib:inflate/2 on the entire attacker-controlled stream, with no bound on output size or 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.

The pure-Erlang RSAES-PKCS1-v1_5 decryption in the jose_jwa_pkcs1 module is a Bleichenbacher padding oracle. eme_pkcs1_decode/2 returns the recovered message when a decrypted block has valid PKCS#1 v1.5 padding and returns a distinct error result otherwise, and rsaes_pkcs1_decrypt/2 additionally returns {error, {badsize, _}} when the length check fails. The implementation applies no implicit-rejection countermeasure (RFC 8017 §7.2.2), so a one-bit padding-conformance signal leaks to the caller. Because the underlying modular exponentiation in dp/2 is a raw, non-blinded crypto:mod_pow/3, the padding check also stays distinguishable by timing even when an application normalizes every failure to a single error value.

The pure-Erlang AES-GCM fallback in jose_jwa_aes derives the number of verified authentication tag bits from the attacker-supplied tag itself. In the {aes_gcm, Bits} clause of block_decrypt/4, the incoming tag is guarded only by is_binary/1, with no check on its length. Verification in gcm_block_decrypt/6 then computes TBits = bit_size(T) and compares only those bits of the real 128-bit tag. An attacker who controls a JWE token can truncate the authentication tag to as little as 8 bits, so only 8 bits are ever checked, reducing forgery resistance from 2^-128 to 2^-8.

The JOSE library before version 0.3.5+1 allows an unauthenticated remote attacker to forge JWS/JWT tokens by using a key embedded in the JOSE header (jwk). The library incorrectly treats header-provided keys as verification candidates even when not in the trusted key store.