erlang-jose CVE-2026-65630

Exploitation requires that the pure-Erlang Curve25519 fallback is the code path actually used - i.e. crypto_fallback is enabled (jose:crypto_fallback(true)/JOSE.crypto_fallback(true) or curve25519_module set to :jose_jwa_curve25519) or no constant-time native X25519 provider (OTP crypto, libdecaf, or libsodium) is available; releases up to 1.11.12 shipped crypto_fallback=true in the jose application environment, so the vulnerable path could be selected even though the README documented fallback as disabled. It further requires that the service performs X25519 scalar multiplication with a reused long-term private key in a timing-observable context, most concretely a service that decrypts attacker-supplied ECDH-ES JWE messages via JOSE.JWK.box_decrypt_ecdh_es/2. Limiting factors: no authentication is needed to submit ciphertexts, but the attacker must obtain large numbers of high-precision, low-noise timing measurements (the PoC uses warmup, 400-sample medians, and interleaved rounds to beat scheduler/JIT noise), reflected in AC:H and AT:P; deployments using a native constant-time provider with crypto_fallback=false (the default from 1.11.13) are not exposed.

This is a genuine but conditional, low-urgency cryptographic weakness rather than a mass-exploitation threat, and the signals are consistent with that reading. The CVSS 4.0 base score is 5.9 (medium) with AC:H and AT:P, reflecting that practical exploitation requires many high-precision, low-noise timing samples against an operation-count-balanced 254-step ladder - a high bar. EPSS is 0.14% (3rd percentile), i.e. very low predicted exploitation, and the vulnerability is not in CISA KEV, so there is no evidence of active exploitation; this aligns with the vendor's 'medium' rating and the vuln.today 'this_month' decision label (a scheduled-remediation priority, not emergency/act_now). The GHSA advisory ships a PoC, but it demonstrates that decryption time is a stable function of the private scalar - not an end-to-end key-recovery exploit - so POC-availability should not be conflated with practical key recovery or active exploitation. Note a vector/mechanism tension: the vendor scored AV:L, yet the described and most dangerous scenario is a network-reachable service decrypting attacker-submitted ECDH-ES JWE messages and leaking timing over the wire, which is naturally a network-facing attack surface; remote timing resolution is extremely noisy, which is likely why AC:H/AT:P and possibly AV:L were chosen - verify the intended attack vector with the vendor. Crucially, exploitability is gated on a non-default-documented code path (pure-Erlang Curve25519 fallback), which materially lowers real-world risk below what the C:H impact alone would suggest.

An Erlang/Elixir service holding a long-term X25519 key decrypts attacker-supplied ECDH-ES (JWE) messages via JOSE.JWK.box_decrypt_ecdh_es/2, which reaches the pure-Erlang jose_jwa_x25519 Montgomery ladder. The attacker repeatedly submits ciphertexts (e.g. reusing a fixed ephemeral point) and measures decryption response time, and because the ladder's bignum arithmetic is value-dependent on the secret scalar, the timing leaks the key bit by bit. A vendor-published PoC demonstrates the secret-correlated timing delta but is not verified as a working end-to-end key-recovery exploit, and the high complexity (AC:H) plus attack requirements (AT:P) make precise measurement the limiting factor.