CVE-2026-65627

The jose library accepts ECDSA (ES256, ES256K, ES384, and ES512) JWS signatures of a non-canonical length. When verifying an ECDSA signature, jose_jwk_kty_ec:verify/4 splits the raw signature in half by its actual byte length instead of enforcing the fixed length required by RFC 7518 §3.4, then decodes each half ignoring leading zero bytes. An attacker holding one valid token can prepend leading zero bytes to each of the R and S halves to produce many distinct signature byte strings that verify against the same key (signature malleability).

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.

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.