CVE-2026-65625 in jose
Summary
by MITRE • 10/26/2026
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. This reduces forgery resistance from 2^-128 to 2^-8, and a forged ciphertext is reliably accepted as authentic within 256 attempts without knowledge of the key (an authentication tag forgery and integrity bypass). Supplying a tag longer than 128 bits instead causes a badmatch that crashes the decrypting process. The fallback is reached through the public JWE decryption path whenever AES-GCM is not provided by a native crypto NIF, for example on FIPS or stripped or older OTP builds.
This issue affects jose: from 1.2.0 before 1.11.13.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/26/2026
The vulnerability identified in the pure-Erlang AES-GCM fallback implementation within the jose_jwa_aes module represents a critical failure in cryptographic integrity verification, specifically classified under CWE-345: Insufficient Verification of Data Authenticity. This flaw arises from an improper handling of authentication tag lengths during the decryption process for JSON Web Encryption tokens. In secure implementations of Galois/Counter Mode encryption, such as AES-GCM, the authentication tag is a fixed-size output that must be verified against the decrypted plaintext and associated data to ensure both confidentiality and integrity. The standard security expectation for AES-GCM with a 128-bit tag is that an attacker has only one in two hundred fifty-six trillion trillion trillion chances of successfully forging a valid token without knowing the secret key, providing robust protection against tampering. However, the affected implementation deviates from this secure baseline by dynamically deriving the number of bits to verify directly from the length of the provided authentication tag rather than enforcing a fixed minimum or maximum length consistent with cryptographic standards.
The technical root cause lies in the block_decrypt/4 function's handling of the {aes_gcm, Bits} clause. The incoming authentication tag is subjected only to an is_binary/1 check, which confirms it is binary data but imposes no constraints on its size. Consequently, when the gcm_block_decrypt/6 function executes, it calculates TBits as the bit_size of the provided tag and proceeds to compare only that specific number of bits from the actual 128-bit authentication tag generated during encryption. This logic allows an attacker who controls a JWE token to truncate the authentication tag significantly before submission. By supplying a tag truncated to merely eight bits, the system reduces the forgery resistance exponentially from two-to-the-power-of-negative-128 down to two-to-the-power-of-negative-eight. This reduction transforms what should be a computationally infeasible attack into a trivial brute-force operation that can succeed within approximately 256 attempts without any knowledge of the encryption key, effectively bypassing integrity checks entirely.
The operational impact of this vulnerability is severe for applications relying on jose_jwa_aes for secure communication or token validation. An attacker can forge valid JWE tokens with high reliability by repeatedly guessing truncated authentication tags until one matches the partial verification performed by the vulnerable code path. This capability enables unauthorized access to protected resources, data tampering that goes undetected, and potential privilege escalation if these tokens are used for session management or authorization decisions. Furthermore, the vulnerability exhibits a secondary denial-of-service characteristic when an attacker supplies an authentication tag longer than 128 bits. In such cases, the mismatch between expected and actual bit sizes triggers a badmatch error in Erlang, causing the decrypting process to crash. This dual nature of the flaw allows for both integrity bypasses through truncation and service disruption through oversized inputs, affecting system availability and reliability.
The vulnerability is specifically triggered when the native crypto NIF (Native Implemented Function) providing AES-GCM support is unavailable or disabled. This scenario commonly occurs on systems running FIPS-compliant Erlang/OTP builds where certain cryptographic algorithms are restricted, as well as in stripped-down or older versions of OTP that lack full native cipher suite support. In these environments, the application falls back to a pure-Erlang implementation which contains this logic error. The affected range spans jose library versions from 1.2.0 up to but not including 1.11.13. To mitigate this risk, organizations must upgrade to version 1.11.13 or later where the tag length validation has been corrected to enforce strict adherence to standard AES-GCM specifications. Until an update is applied, administrators should ensure that native crypto NIFs are properly configured and available on all deployment targets to bypass the vulnerable pure-Erlang fallback path entirely. Additionally, implementing defense-in-depth strategies such as validating token structures at the application layer before passing them to cryptographic libraries can provide supplementary protection against malformed inputs. This incident underscores the importance of rigorous input validation in cryptographic implementations, particularly when handling variable-length authentication data that dictates security parameters.