{"id":"CVE-2026-65631","aliases":["AZL-112202","DEBIAN-CVE-2026-65631","EEF-CVE-2026-65631","EUVD-2026-110309","GHSA-3m45-vrpj-xmrq","UBUNTU-CVE-2026-65631"],"status":"published","title":"erlang-jose RSA JWK parsing attempts to factor an attacker-controlled modulus, enabling CPU-exhaustion denial of service","description":"Inefficient Algorithmic Complexity in erlang-jose allows an unauthenticated remote attacker to cause a CPU-exhaustion denial of service by submitting a crafted RSA JSON Web Key.\n\nWhen an application parses an untrusted JWK through the public jose_jwk:from_binary/1 or jose_jwk:from_map/1 API (or the Elixir wrappers JOSE.JWK.from_binary/1 and JOSE.JWK.from_map/1), an RSA private key that supplies d, e, and n but omits all Chinese Remainder Theorem parameters (p, q, dp, dq, qi) is routed into convert_sfm_to_crt/1, which tries to recover the missing primes by factoring the modulus. The three integers are read straight from the base64url input and are never validated as a real RSA key. When the modulus cannot be split into two factors (for example, when it is itself prime), the search loop convert_sfm_to_crt_find_p/6 performs a modular exponentiation over the attacker-sized modulus on every iteration and never succeeds. A single request of a few hundred bytes forces close to one CPU-second of work before an internal one-second watchdog kills the worker, and a larger modulus raises the cost further. By flooding such requests an attacker can saturate every scheduler and deny service, without credentials, a valid RSA key, or any special configuration.\n\nThis issue affects jose: from 1.7.7 before 1.11.13.","severity":{"version":"4.0","score":6.9,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-10","score":0.00235,"percentile":0.1448,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-407"],"published":"2026-10-26T19:53:45Z","modified":"2026-11-10T04:00:09Z","fixes":[{"ecosystem":"Debian:14","package":"erlang-jose","fixed_in":["1.11.13-1"],"sources":["osv"]},{"ecosystem":"Hex","package":"jose","fixed_in":["1.11.13"],"sources":["osv"]}],"affected":[{"source":"osv","ecosystem":"Azure Linux:3","package":"rabbitmq-server","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"3.13.7-11"}]}]},{"source":"osv","ecosystem":"Debian:12","package":"erlang-jose","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1.11.10-1","1.11.10-1~bpo12+1","1.11.12-1","1.11.12-1.1","1.11.12-2","1.11.12-2~bpo13+1","1.11.12-3","1.11.12-3~bpo13+1","1.11.13-1","1.11.5-1","1.11.6-1","1.11.6-1~bpo12+1"]},{"source":"osv","ecosystem":"Debian:13","package":"erlang-jose","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1.11.10-1","1.11.12-1","1.11.12-1.1","1.11.12-2","1.11.12-2~bpo13+1","1.11.12-3","1.11.12-3~bpo13+1","1.11.13-1"]},{"source":"osv","ecosystem":"Debian:14","package":"erlang-jose","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.11.13-1"}]}],"versions":["1.11.10-1","1.11.12-1","1.11.12-1.1","1.11.12-2","1.11.12-2~bpo13+1","1.11.12-3","1.11.12-3~bpo13+1"]},{"source":"osv","ecosystem":"Hex","package":"jose","ranges":[{"type":"SEMVER","events":[{"introduced":"1.7.7"},{"fixed":"1.11.13"}]}],"versions":["1.10.0","1.10.1","1.11.0","1.11.1","1.11.10","1.11.11","1.11.12","1.11.2","1.11.4","1.11.5","1.11.6","1.11.7","1.11.8","1.11.9","1.7.7","1.7.8","1.7.9","1.8.0","1.8.1","1.8.2","1.8.3","1.8.4","1.9.0"]},{"source":"osv","ecosystem":"Ubuntu:18.04:LTS","package":"jose","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["10-2","10-2build1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"jose","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["10-2build2"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"jose","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["10-3","11-2"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"jose","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["11-2","11-3","11-3build1","11-3build2","13-1"]},{"source":"osv","ecosystem":"Ubuntu:26.10","package":"jose","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["14-2build1","14-2build2"]},{"source":"osv","ecosystem":"Ubuntu:26.04:LTS","package":"jose","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["14-2build1"]}],"products":[{"vendor":"appsup-dart","product":"jose"},{"vendor":"potatosalad","product":"jose"}],"references":[{"url":"https://github.com/potatosalad/erlang-jose/security/advisories/GHSA-3m45-vrpj-xmrq","tags":["vendor-advisory","related","advisory"]},{"url":"https://cna.erlef.org/cves/CVE-2026-65631.html","tags":["related","web"]},{"url":"https://osv.dev/vulnerability/EEF-CVE-2026-65631","tags":["related","web"]},{"url":"https://github.com/potatosalad/erlang-jose/commit/d19e1ba68d88c68d29aa942be2573a22dbafca1f","tags":["related","fix","web","report"]},{"url":"https://github.com/potatosalad/erlang-jose/commit/bfd336c0062bff93e65d08c22361897e96afd956","tags":["patch","fix","report"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-65631","tags":["web","advisory"]},{"url":"https://github.com","tags":["web","report"]},{"url":"https://repo.hex.pm","tags":["web","report"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/65xxx/CVE-2026-65631.json","tags":["advisory"]},{"url":"https://github.com/potatosalad/erlang-jose","tags":["package","report"]},{"url":"https://security-tracker.debian.org/tracker/CVE-2026-65631","tags":["advisory"]},{"url":"https://hex.pm/packages/jose","tags":["package","report"]},{"url":"https://ubuntu.com/security/CVE-2026-65631","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-65631","tags":["report"]},{"url":"https://cna.erlef.org/cves/cve-2026-65631.html","tags":["report"]},{"url":"https://github.com/potatosalad/erlang-jose/security/advisories/ghsa-3m45-vrpj-xmrq","tags":["report"]},{"url":"https://github.com/cveproject/cvelistv5/tree/main/cves/2026/65xxx/cve-2026-65631.json","tags":["report"]},{"url":"https://nvd.nist.gov/vuln/detail/cve-2026-65631","tags":["report"]},{"url":"https://osv.dev/vulnerability/eef-cve-2026-65631","tags":["report"]}],"sources":{"cve":[{"id":"CVE-2026-65631","title":"erlang-jose RSA JWK parsing attempts to factor an attacker-controlled modulus, enabling CPU-exhaustion denial of service","description":"Inefficient Algorithmic Complexity in erlang-jose allows an unauthenticated remote attacker to cause a CPU-exhaustion denial of service by submitting a crafted RSA JSON Web Key.\n\nWhen an application parses an untrusted JWK through the public jose_jwk:from_binary/1 or jose_jwk:from_map/1 API (or the Elixir wrappers JOSE.JWK.from_binary/1 and JOSE.JWK.from_map/1), an RSA private key that supplies d, e, and n but omits all Chinese Remainder Theorem parameters (p, q, dp, dq, qi) is routed into convert_sfm_to_crt/1, which tries to recover the missing primes by factoring the modulus. The three integers are read straight from the base64url input and are never validated as a real RSA key. When the modulus cannot be split into two factors (for example, when it is itself prime), the search loop convert_sfm_to_crt_find_p/6 performs a modular exponentiation over the attacker-sized modulus on every iteration and never succeeds. A single request of a few hundred bytes forces close to one CPU-second of work before an internal one-second watchdog kills the worker, and a larger modulus raises the cost further. By flooding such requests an attacker can saturate every scheduler and deny service, without credentials, a valid RSA key, or any special configuration.\n\nThis issue affects jose: from 1.7.7 before 1.11.13.","status":"published","published":"2026-10-26T19:53:45.204Z","modified":"2026-11-03T17:31:26.989Z","cvss":[{"version":"4.0","score":6.9,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"medium","assessor":"cna"}],"cwes":["CWE-407"],"updated_at":"2026-11-03T19:01:23.264561Z"}],"euvd":[{"id":"EUVD-2026-110309","description":"Inefficient Algorithmic Complexity in erlang-jose allows an unauthenticated remote attacker to cause a CPU-exhaustion denial of service by submitting a crafted RSA JSON Web Key.\n\nWhen an application parses an untrusted JWK through the public jose_jwk:from_binary/1 or jose_jwk:from_map/1 API (or the Elixir wrappers JOSE.JWK.from_binary/1 and JOSE.JWK.from_map/1), an RSA private key that supplies d, e, and n but omits all Chinese Remainder Theorem parameters (p, q, dp, dq, qi) is routed into convert_sfm_to_crt/1, which tries to recover the missing primes by factoring the modulus. The three integers are read straight from the base64url input and are never validated as a real RSA key. When the modulus cannot be split into two factors (for example, when it is itself prime), the search loop convert_sfm_to_crt_find_p/6 performs a modular exponentiation over the attacker-sized modulus on every iteration and never succeeds. A single request of a few hundred bytes forces close to one CPU-second of work before an internal one-second watchdog kills the worker, and a larger modulus raises the cost further. By flooding such requests an attacker can saturate every scheduler and deny service, without credentials, a valid RSA key, or any special configuration.\n\nThis issue affects jose: from 1.7.7 before 1.11.13.","status":"published","published":"2026-10-26T19:53:45Z","modified":"2026-11-03T17:31:26Z","cvss":[{"version":"4.0","score":6.9,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"medium"}],"updated_at":"2026-11-03T19:19:17.549112Z"}],"nvd":[{"id":"CVE-2026-65631","description":"Inefficient Algorithmic Complexity in erlang-jose allows an unauthenticated remote attacker to cause a CPU-exhaustion denial of service by submitting a crafted RSA JSON Web Key.\n\nWhen an application parses an untrusted JWK through the public jose_jwk:from_binary/1 or jose_jwk:from_map/1 API (or the Elixir wrappers JOSE.JWK.from_binary/1 and JOSE.JWK.from_map/1), an RSA private key that supplies d, e, and n but omits all Chinese Remainder Theorem parameters (p, q, dp, dq, qi) is routed into convert_sfm_to_crt/1, which tries to recover the missing primes by factoring the modulus. The three integers are read straight from the base64url input and are never validated as a real RSA key. When the modulus cannot be split into two factors (for example, when it is itself prime), the search loop convert_sfm_to_crt_find_p/6 performs a modular exponentiation over the attacker-sized modulus on every iteration and never succeeds. A single request of a few hundred bytes forces close to one CPU-second of work before an internal one-second watchdog kills the worker, and a larger modulus raises the cost further. By flooding such requests an attacker can saturate every scheduler and deny service, without credentials, a valid RSA key, or any special configuration.\n\nThis issue affects jose: from 1.7.7 before 1.11.13.","status":"published","published":"2026-10-26T20:17:58.997Z","modified":"2026-11-03T18:18:04.273Z","cvss":[{"version":"4.0","score":6.9,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/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","level":"medium","assessor":"secondary"}],"cwes":["CWE-407"],"updated_at":"2026-11-03T20:18:17.584337Z"}],"osv":[{"id":"CVE-2026-65631","title":"erlang-jose RSA JWK parsing attempts to factor an attacker-controlled modulus, enabling CPU-exhaustion denial of service","description":"Inefficient Algorithmic Complexity in erlang-jose allows an unauthenticated remote attacker to cause a CPU-exhaustion denial of service by submitting a crafted RSA JSON Web Key.\n\nWhen an application parses an untrusted JWK through the public jose_jwk:from_binary/1 or jose_jwk:from_map/1 API (or the Elixir wrappers JOSE.JWK.from_binary/1 and JOSE.JWK.from_map/1), an RSA private key that supplies d, e, and n but omits all Chinese Remainder Theorem parameters (p, q, dp, dq, qi) is routed into convert_sfm_to_crt/1, which tries to recover the missing primes by factoring the modulus. The three integers are read straight from the base64url input and are never validated as a real RSA key. When the modulus cannot be split into two factors (for example, when it is itself prime), the search loop convert_sfm_to_crt_find_p/6 performs a modular exponentiation over the attacker-sized modulus on every iteration and never succeeds. A single request of a few hundred bytes forces close to one CPU-second of work before an internal one-second watchdog kills the worker, and a larger modulus raises the cost further. By flooding such requests an attacker can saturate every scheduler and deny service, without credentials, a valid RSA key, or any special configuration.\n\nThis issue affects jose: from 1.7.7 before 1.11.13.","status":"published","published":"2026-10-26T19:53:45.204Z","modified":"2026-11-05T02:30:51.183015896Z","cvss":[{"version":"4.0","score":6.9,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"medium"}],"cwes":["CWE-407"],"updated_at":"2026-11-07T03:08:08.86544Z"},{"id":"DEBIAN-CVE-2026-65631","description":"Inefficient Algorithmic Complexity in erlang-jose allows an unauthenticated remote attacker to cause a CPU-exhaustion denial of service by submitting a crafted RSA JSON Web Key.  When an application parses an untrusted JWK through the public jose_jwk:from_binary/1 or jose_jwk:from_map/1 API (or the Elixir wrappers JOSE.JWK.from_binary/1 and JOSE.JWK.from_map/1), an RSA private key that supplies d, e, and n but omits all Chinese Remainder Theorem parameters (p, q, dp, dq, qi) is routed into convert_sfm_to_crt/1, which tries to recover the missing primes by factoring the modulus. The three integers are read straight from the base64url input and are never validated as a real RSA key. When the modulus cannot be split into two factors (for example, when it is itself prime), the search loop convert_sfm_to_crt_find_p/6 performs a modular exponentiation over the attacker-sized modulus on every iteration and never succeeds. A single request of a few hundred bytes forces close to one CPU-second of work before an internal one-second watchdog kills the worker, and a larger modulus raises the cost further. By flooding such requests an attacker can saturate every scheduler and deny service, without credentials, a valid RSA key, or any special configuration.  This issue affects jose: from 1.7.7 before 1.11.13.","status":"published","published":"2026-10-26T20:17:58.997Z","modified":"2026-11-10T04:00:09.826196506Z","cvss":[{"version":"4.0","score":6.9,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/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","level":"medium"}],"updated_at":"2026-11-10T04:22:10.004764Z"},{"id":"EEF-CVE-2026-65631","title":"erlang-jose RSA JWK parsing attempts to factor an attacker-controlled modulus, enabling CPU-exhaustion denial of service","description":"## Summary\n\nInefficient Algorithmic Complexity in erlang-jose allows an unauthenticated remote attacker to cause a CPU-exhaustion denial of service by submitting a crafted RSA JSON Web Key.\n\nWhen an application parses an untrusted JWK through the public `jose_jwk:from_binary/1` or `jose_jwk:from_map/1` API (or the Elixir wrappers `JOSE.JWK.from_binary/1` and `JOSE.JWK.from_map/1`), an RSA private key that supplies `d`, `e`, and `n` but omits all Chinese Remainder Theorem parameters (`p`, `q`, `dp`, `dq`, `qi`) is routed into `convert_sfm_to_crt/1`, which tries to recover the missing primes by factoring the modulus. The three integers are read straight from the base64url input and are never validated as a real RSA key. When the modulus cannot be split into two factors (for example, when it is itself prime), the search loop `convert_sfm_to_crt_find_p/6` performs a modular exponentiation over the attacker-sized modulus on every iteration and never succeeds. A single request of a few hundred bytes forces close to one CPU-second of work before an internal one-second watchdog kills the worker, and a larger modulus raises the cost further. By flooding such requests an attacker can saturate every scheduler and deny service, without credentials, a valid RSA key, or any special configuration.\n\nThis issue affects jose: from 1.7.7 before 1.11.13.","status":"published","published":"2026-10-26T19:53:45.204Z","modified":"2026-10-26T20:11:07.68246801Z","cvss":[{"version":"4.0","score":6.9,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"medium"}],"cwes":["CWE-407"],"updated_at":"2026-11-02T15:46:33.520522Z"},{"id":"UBUNTU-CVE-2026-65631","description":"Inefficient Algorithmic Complexity in erlang-jose allows an unauthenticated remote attacker to cause a CPU-exhaustion denial of service by submitting a crafted RSA JSON Web Key. When an application parses an untrusted JWK through the public jose_jwk:from_binary/1 or jose_jwk:from_map/1 API (or the Elixir wrappers JOSE.JWK.from_binary/1 and JOSE.JWK.from_map/1), an RSA private key that supplies d, e, and n but omits all Chinese Remainder Theorem parameters (p, q, dp, dq, qi) is routed into convert_sfm_to_crt/1, which tries to recover the missing primes by factoring the modulus. The three integers are read straight from the base64url input and are never validated as a real RSA key. When the modulus cannot be split into two factors (for example, when it is itself prime), the search loop convert_sfm_to_crt_find_p/6 performs a modular exponentiation over the attacker-sized modulus on every iteration and never succeeds. A single request of a few hundred bytes forces close to one CPU-second of work before an internal one-second watchdog kills the worker, and a larger modulus raises the cost further. By flooding such requests an attacker can saturate every scheduler and deny service, without credentials, a valid RSA key, or any special configuration. This issue affects jose: from 1.7.7 before 1.11.13.","status":"published","published":"2026-10-26T20:17:00Z","modified":"2026-10-28T20:17:47.957495678Z","cvss":[{"version":"4.0","score":6.9,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"medium"},{"version":"4.0","score":6.9,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"medium"}],"updated_at":"2026-11-02T16:56:53.710209Z"},{"id":"AZL-112202","title":"CVE-2026-65631 affecting package rabbitmq-server 3.13.7-11","description":"Inefficient Algorithmic Complexity in erlang-jose allows an unauthenticated remote attacker to cause a CPU-exhaustion denial of service by submitting a crafted RSA JSON Web Key.\n\nWhen an application parses an untrusted JWK through the public jose_jwk:from_binary/1 or jose_jwk:from_map/1 API (or the Elixir wrappers JOSE.JWK.from_binary/1 and JOSE.JWK.from_map/1), an RSA private key that supplies d, e, and n but omits all Chinese Remainder Theorem parameters (p, q, dp, dq, qi) is routed into convert_sfm_to_crt/1, which tries to recover the missing primes by factoring the modulus. The three integers are read straight from the base64url input and are never validated as a real RSA key. When the modulus cannot be split into two factors (for example, when it is itself prime), the search loop convert_sfm_to_crt_find_p/6 performs a modular exponentiation over the attacker-sized modulus on every iteration and never succeeds. A single request of a few hundred bytes forces close to one CPU-second of work before an internal one-second watchdog kills the worker, and a larger modulus raises the cost further. By flooding such requests an attacker can saturate every scheduler and deny service, without credentials, a valid RSA key, or any special configuration.\n\nThis issue affects jose: from 1.7.7 before 1.11.13.","status":"published","published":"2026-10-26T20:17:58Z","modified":"2026-11-05T14:16:36.862987264Z","updated_at":"2026-11-05T16:41:19.001909Z"}]}}