{"id":"CVE-2026-65628","kind":"vulnerability","aliases":["CVE-2026-65628"],"related":[],"title":"Elixir jose: mismatched JWK types cause endless loop and denial of service","description":"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.\n\nAn 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.\n\nThis issue affects jose: from 1.5.0 before 1.11.13.","summary":"The jose Elixir library's shared secret derivation loops forever when two JWKs have different key types, such as an EC key and an RSA key. An attacker who supplies a crafted peer JWK to an application that derives shared secrets from it can pin Erlang schedulers at 100% CPU and take the service down.","severity":"medium","cvss":5.9,"epss":null,"exploited":false,"exploited_at":null,"products":[],"ecosystems":[],"tags":["ecdh","elixir","erlang","jose","jwt","package"],"not_affected_if":["default-config","no-external-peer-keys"],"how_to_check":"- Run `mix deps | grep jose` or inspect `mix.lock` for the `jose` version in use\n- Search application code for `JOSE.JWK.shared_secret` calls whose peer key comes from request input","fix":"- Upgrade the `jose` Hex package to `1.11.13` or later\n- Validate that the peer JWK's kty and curve match your own key before calling `JOSE.JWK.shared_secret`","status":"open","published_at":"2026-10-26T20:17:58+00:00","first_seen_at":"2026-10-26T20:50:17+00:00","triaged_at":"2026-10-26T20:51:49+00:00","updated_at":"2026-10-26T20:51:49+00:00","category":"package","confidence":0.7,"triage":{"at":"2026-10-26T20:51:49Z","model":"claude-haiku-5-5","output":{"fix":"- Upgrade the `jose` Hex package to `1.11.13` or later\n- Validate that the peer JWK's kty and curve match your own key before calling `JOSE.JWK.shared_secret`","reach":"internet","title":"Elixir jose: mismatched JWK types cause endless loop and denial of service","impact":"medium","summary":"The jose Elixir library's shared secret derivation loops forever when two JWKs have different key types, such as an EC key and an RSA key. An attacker who supplies a crafted peer JWK to an application that derives shared secrets from it can pin Erlang schedulers at 100% CPU and take the service down.","category":"package","nicknames":[],"who_cares":["elixir","jose","erlang","jwt","ecdh"],"confidence":0.7,"needs_auth":"unknown","worst_case":"Erlang schedulers spin forever, denying service to the application","analyst_note":"Check the jose changelog or GitHub advisory to confirm which endpoints or APIs in typical apps reach shared_secret with attacker-supplied keys, and whether a remote request is required.","how_to_check":"- Run `mix deps | grep jose` or inspect `mix.lock` for the `jose` version in use\n- Search application code for `JOSE.JWK.shared_secret` calls whose peer key comes from request input","needs_analyst":true,"not_affected_if":["default-config","no-external-peer-keys"],"who_is_affected":"Applications using the jose Elixir library from version 1.5.0 up to but not including 1.11.13 that call JOSE.JWK.shared_secret/2 with a peer public key supplied by an external party. Applications that only use keys they generate or load from trusted configuration, or that do not derive ECDH shared secrets, are not exposed.","user_interaction":"no","needs_special_setup":"unknown","severity_if_unknown":"medium"},"cost_usd":0.000682,"input_tokens":3594,"output_tokens":645,"severity_before":"medium"},"analyst_status":null,"analyst_note":null,"search":"'-2026':14A,17A '-65628':15A,18A '1.11.13':245C '1.5.0':243C '100':73B,224C 'affect':240C 'alreadi':133C 'already-pars':132C 'applic':61B,179C 'argument':164C 'attack':52B,216C 'attacker-control':215C 'avail':230C 'carri':106C 'caus':6A 'check':194C 'claus':100C,116C,158C 'control':217C 'cpu':74B,225C 'craft':56B 'crash':177C 'curv':202C 'cve':13A,16A 'denial':10A,235C 'deriv':32B,63B,89C,181C 'differ':39B,145C 'driven':209C 'ec':45B,149C 'ecdh':19B,91C 'elixir':1A,20B,27B,85C 'endless':7A 'enter':161C 'erlang':21B,70B,221C 'exampl':147C 'exhaust':228C 'expos':83C 'extern':187C 'fallback':115C,157C 'first':98C,193C 'forev':34B 'from/1':129C 'function':99C 'ident':163C 'invok':119C 'issu':239C 'jose':2A,22B,26B,79C,135C,241C 'jose.jwk.shared':87C 'jwk':4A,58B,80C,136C,218C 'jwks':37B,96C,105C,141C 'jwt':23B 'key':40B,46B,50B,109C,143C,150C,154C,191C,198C,206C 'kti':111C 'librari':28B 'loop':8A,33B,171C,212C 'make':155C 'match':102C,203C 'mismatch':3A 'modul':112C 'myjwk':127C 'never':173C,176C 'packag':24B 'pars':134C 'pass':139C 'peer':57B,189C,197C 'pin':69B,219C 'produc':165C 'public':190C 're':118C,160C 're-ent':159C 're-invok':117C 'record':137C 'recurs':170C 'repeat':226C 'request':227C 'result':232C 'return':130C,174C 'rsa':49B,153C 'schedul':71B,222C,231C 'secret':31B,65B,93C,123C,184C 'secret/2':82C,88C 'servic':12A,78B,237C 'share':30B,64B,81C,92C,122C,183C 'suppli':54B,188C 'tail':169C 'tail-recurs':168C 'take':76B 'two':36B,95C,140C 'type':5A,41B,110C,144C,200C 'unbound':167C 'unchang':138C 'whose':142C 'without':192C 'yourjwk':125C","nicknames":[],"mitigations":[],"who_affected":"Applications using the jose Elixir library from version 1.5.0 up to but not including 1.11.13 that call JOSE.JWK.shared_secret/2 with a peer public key supplied by an external party. Applications that only use keys they generate or load from trusted configuration, or that do not derive ECDH shared secrets, are not exposed.","tier":"C","verified":{},"analyst_revisit_at":null,"first_public_at":"2026-10-26T20:17:58+00:00","kev":null,"cvss_vector":"CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","cvss_by":"6b3ad84c-e1a6-4bf7-a703-f496b71e49db","poc_count":0,"sources":[{"source":"nvd","external_id":"CVE-2026-65628","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-65628","severity":null,"published_at":"2026-10-26T20:17:58+00:00","modified_at":"2026-10-26T20:17:58+00:00","first_seen_at":"2026-10-26T20:50:17+00:00","fetched_at":"2026-10-26T20:50:17+00:00","note":null}],"documents":[],"notice":"Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai"}