CVE-2026-65628 in jose
Summary
by MITRE • 10/26/2026
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 (for example an EC key and an RSA key) makes the fallback clause re-enter with identical arguments, producing an unbounded tail-recursive loop that never returns and never crashes.
An application that derives a shared secret from an externally supplied peer public key without first checking that the peer key's type and curve match its own key can be driven into this loop by an attacker-controlled JWK, pinning an Erlang scheduler at 100% CPU. Repeated requests exhaust the available schedulers, resulting in a denial of service.
This issue affects jose: from 1.5.0 before 1.11.13.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/26/2026
The JOSE library for Elixir and Erlang contains a critical logic error within its Elliptic Curve Diffie-Hellman shared secret derivation function, specifically in the jose_jwk:shared_secret/2 implementation exposed as JOSE.JWK.shared_secret/2. This vulnerability stems from an incorrect handling of key type mismatches during cryptographic operations. The function is designed to derive a shared secret using two JSON Web Key objects, requiring that both keys be compatible for the specific algorithm being executed. However, the internal logic relies on pattern matching where the first clause only succeeds if both JWKs share the same key type module identifier. When this condition fails because the key types differ, such as when one is an Elliptic Curve key and the other is an RSA key, control falls through to a fallback clause intended for normalization or conversion.
The core technical flaw lies in how this fallback clause operates. Instead of returning an error tuple indicating that the operation cannot proceed due to incompatible key types, the function recursively invokes itself by calling shared_secret(from(YourJWK), from(MyJWK)). The helper function from/1 is designed to parse and normalize JWK structures but returns already-parsed jose_jwk records unchanged if they are not strings or maps. Consequently, when two distinct JWKs with mismatched key types are passed in, the recursive call receives arguments that are structurally identical to the original input because no transformation occurs. This creates an infinite tail-recursive loop where the function calls itself indefinitely without any base case being reached and without raising a runtime exception or stack overflow error typical of such loops in Erlang/Elixir environments.
From a security impact perspective, this vulnerability manifests as a severe Denial of Service condition. An attacker who can supply externally controlled JWK data to an application that performs key agreement operations can trigger this infinite loop by providing a public key with a mismatched type relative to the server's private or public key. Because Erlang schedulers are pinned to specific CPU cores, a single thread entering an unbounded recursive loop will consume one hundred percent of that core's processing capacity indefinitely. If multiple such requests are sent concurrently, they can exhaust all available scheduler threads within the BEAM virtual machine. This results in complete application unresponsiveness, effectively rendering the service unavailable to legitimate users and causing significant operational disruption without requiring any authentication or privilege escalation.
This issue is classified under CWE-835, which describes a loop involving an infinite wait condition, specifically resulting from incorrect logic that fails to handle invalid input states appropriately. In terms of attack vectors, this aligns with ATT&CK technique T1499, Endpoint Denial of Service, where the attacker leverages resource exhaustion through computational complexity or unbounded loops rather than traditional buffer overflows or memory corruption exploits. The vulnerability highlights a common pitfall in functional programming libraries where error handling is omitted in favor of silent recursion, assuming that input validation occurs at higher levels of the application stack.
The affected versions include jose from 1.5.0 up to but not including version 1.11.13. To mitigate this vulnerability, organizations must upgrade their dependencies to JOSE library version 1.11.13 or later, where the logic has been corrected to properly detect key type mismatches and return an appropriate error instead of entering a recursive loop. For applications that cannot immediately update due to dependency constraints, defensive programming practices should be implemented at the application layer. This involves explicitly validating the kty (key type) parameter of any externally supplied JWK before passing it to cryptographic functions. Developers must ensure that both keys involved in an ECDH operation are confirmed to use compatible curves and key types prior to invoking shared secret derivation routines, thereby preventing malformed or malicious inputs from reaching the vulnerable library function.