CVE-2026-65626
MediumCVSS 5.9Exploitation Probability (EPSS)
Low risk0th percentile - higher than 0% of all known CVEs
Summary
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.
Risk Assessment
An unauthenticated attacker who knows only the public RSA key and can submit ciphertexts to a decryption endpoint that unwraps RSA1_5 JWE keys can use this oracle to recover the plaintext of intercepted ciphertexts (such as content-encryption keys and thus the protected message) or to forge signatures through roughly 10^4 to 10^6 adaptive chosen-ciphertext queries.
Recommendation
Upgrade the jose library to version 1.11.13 or later. Avoid RSA1_5 decryption on untrusted input and consider migrating to newer key-management algorithms (e.g., RSA-OAEP).
Other vulnerabilities in jose
See all- CVE-2026-65632Medium
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).
- CVE-2026-65631Medium
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.
- CVE-2026-65630Medium
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.
- CVE-2026-65629High
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.
- CVE-2026-65628Medium
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.
- CVE-2026-65627Medium
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.
- CVE-2026-65625Medium
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.
- CVE-2026-34240High
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.
Original NVD description (English source)
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 (a leading 0x00 0x02, a padding string of at least eight non-zero bytes, and a 0x00 separator) 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): it does not substitute a deterministic pseudo-random plaintext on a padding failure, 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. An unauthenticated attacker who knows only the public RSA key and can submit ciphertexts to a decryption endpoint that unwraps RSA1_5 JWE keys (or otherwise calls decrypt_private/3 with rsa_pkcs1_padding) can use this oracle to recover the plaintext of intercepted ciphertexts, such as content-encryption keys and thus the protected message, or to forge signatures, through roughly 10^4 to 10^6 adaptive chosen-ciphertext queries. This issue affects jose: from 1.3.0 before 1.11.13.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

