Erlang jose EUVD-2026-110307

Exploitation requires that the application call jose_jwk:shared_secret/2 (Elixir JOSE.JWK.shared_secret/2) to derive an ECDH shared secret using an externally supplied peer public JWK, AND that it does so without first validating that the peer key's kty (and crv for EC/OKP keys) matches its own key - the advisory's stated vulnerable pattern. The attacker then sends a single JWK whose kty differs from the server's key (e.g. an RSA public key against the server's EC P-256 key), which is enough to hang the deriving process indefinitely. No authentication or privilege is needed beyond the ability to submit a peer key to the derivation flow (PR:N, UI:N). Limiting factors: only affects deployments on jose 1.5.0 through before 1.11.13 that actually use the shared_secret/2 ECDH path on untrusted input - applications using jose solely for JWS/JWE/JWT signing and verification do not reach the vulnerable clause.

This is a genuine but modest-priority availability issue, not a drop-everything emergency. The vendor CVSS 4.0 score is 5.9 (medium), with impact confined to availability (VA:H; VC/VI:N) - there is no confidentiality or integrity exposure, only CPU-exhaustion denial-of-service via an infinite tail-recursive loop (CWE-674/835). EPSS is very low at 0.14% (3rd percentile) and the CVE is NOT in CISA KEV, so there is no sign of active or widespread exploitation. Countervailing that, a verified public proof-of-concept exploit script (with run logs showing a hung scheduler) is published in the GHSA advisory, and the trigger is a single crafted request requiring no authentication (PR:N) and no user interaction (UI:N), making it trivially automatable once a vulnerable code path is reachable. The signals conflict on attack vector: the supplied CVSS 4.0 vector asserts AV:L (local), yet the advisory describes a remotely triggerable DoS where an attacker-controlled peer JWK arrives over the wire in an ordinary ECDH key-agreement endpoint - treat the realistic vector as network-reachable and verify with the vendor rather than trusting AV:L. The AT:P (attack requirements) metric reflects the real limiter: the flaw is only reachable when an application derives a shared secret from an untrusted peer key without first checking kty/crv, which is a narrower usage pattern than generic JWT signing/verification. Net: for operators running Elixir/Erlang services that perform ECDH shared-secret derivation with jose on externally supplied keys, this warrants prompt patching (consistent with the vuln.today 'this_month' decision label); for everyone else using jose only for JWS/JWE/JWT, real exposure is low.

An unauthenticated remote attacker submits an attacker-controlled peer public JWK of a mismatched key type (for example an RSA key) to an application that derives an ECDH shared secret against its own EC P-256 key via JOSE.JWK.shared_secret/2 on untrusted input. The kty mismatch makes the function re-enter itself with identical arguments, pinning a BEAM scheduler at 100% CPU per request so the call never returns; repeated requests exhaust the available schedulers and take the service down. A verified public proof-of-concept script demonstrating this is published in the GHSA advisory.