CVE-2026-65626 in jose
Summary
by MITRE • 10/26/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/26/2026
The vulnerability identified in the jose library's implementation of RSAES-PKCS1-v1_5 decryption constitutes a critical Bleichenbacher padding oracle attack vector within the jose_jwa_pkcs1 module. This flaw arises from the specific behavior of the eme_pkcs1_decode/2 function, which explicitly distinguishes between valid and invalid PKCS#1 v1.5 padding structures by returning the recovered message for valid inputs and a distinct error result otherwise. Furthermore, the rsaes_pkcs1_decrypt/2 function introduces an additional signal by returning a specific {error, {badsize, _}} tuple when length checks fail. This explicit differentiation violates the fundamental security requirement outlined in RFC 8017 Section 7.2.2, which mandates that implementations must not leak information about padding validity to prevent adaptive chosen-ciphertext attacks. The absence of implicit rejection countermeasures means that an attacker can observe whether a decrypted block conforms to the expected padding format, providing a binary signal that is essential for executing statistical analysis against the cryptographic material.
The severity of this vulnerability is compounded by the underlying implementation details regarding modular exponentiation. The dp/2 function relies on raw, non-blinded calls to crypto:mod_pow/3. In secure cryptographic implementations, randomization or blinding techniques are employed during modular exponentiation to mask timing variations that could otherwise leak information about secret keys through side-channel attacks. Because this library uses a deterministic and unblinded approach, the padding check remains distinguishable by execution time even if an application layer attempts to normalize error responses into a single generic failure message. This means that both explicit response differences and subtle timing discrepancies can be exploited simultaneously, significantly lowering the barrier for successful exploitation compared to implementations where only one channel of leakage exists.
An unauthenticated attacker possessing knowledge of the public RSA key can exploit this oracle by submitting crafted ciphertexts to any decryption endpoint that unwraps RSA1_5 JWE keys or invokes decrypt_private/3 with rsa_pkcs1_padding. By analyzing the responses, specifically the distinction between padding errors and other failures as well as timing variations, the attacker can perform an adaptive chosen-ciphertext attack. This process involves approximately 10^4 to 10^6 queries to systematically narrow down the possible plaintext values until the original message is recovered. The operational impact of this exploitation is severe; it allows for the recovery of content-encryption keys embedded within JWE payloads, thereby enabling the decryption of protected messages without authorization. Additionally, depending on the specific usage context and protocol interactions, such an oracle can potentially be leveraged to forge signatures or manipulate cryptographic operations that rely on the confidentiality of RSA-decrypted values.
This vulnerability affects versions of the jose library from 1.3.0 up to but not including version 1.11.13. To mitigate this risk, organizations must upgrade immediately to a patched version where implicit rejection is implemented correctly and modular exponentiation operations are blinded according to current cryptographic best practices. Until an upgrade is performed, applications should consider implementing application-level mitigations such as constant-time comparison for all error paths and ensuring that no distinct feedback regarding padding validity or decryption success is returned to the client. It is also advisable to review access controls on any endpoints performing RSA decryption to ensure they are not exposed to unauthenticated actors who could conduct the necessary adaptive queries required for this attack. The classification of this issue aligns with CWE-358, Improperly Implemented Security Check For Standard, and maps to MITRE ATT&CK techniques related to Cryptographic Failures and Adaptive Chosen-Ciphertext Attacks, highlighting the need for rigorous adherence to standard-compliant cryptographic implementations in all security-sensitive software components.