---
id: "CVE-2026-65631"
kind: "vulnerability"
aliases: ["CVE-2026-65631"]
title: "erlang-jose: crafted RSA JWK parsing exhausts CPU, denying service"
severity: "medium"
cvss: 6.9
epss: null
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["api", "elixir", "erlang", "jose", "package", "self-hosted"]
not_affected_if: ["jose-below-1.7.7", "no-untrusted-jwk-input"]
published_at: "2026-10-26T20:17:58+00:00"
first_seen_at: "2026-10-26T20:50:18+00:00"
updated_at: "2026-10-26T20:51:42+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-65631", "first_seen_at": "2026-10-26T20:50:18+00:00"}]
---

# erlang-jose: crafted RSA JWK parsing exhausts CPU, denying service

The erlang-jose library, used by Elixir and Erlang apps, spends about a CPU-second per crafted RSA JSON Web Key when parsing it, because it tries to factor the modulus. An unauthenticated attacker flooding such requests can saturate every scheduler and deny service.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Check the locked jose version in `mix.lock` (Elixir) or `rebar.lock` (Erlang) and see if it is from `1.7.7` up to but not including `1.11.13`.
- Look for code that calls `JOSE.JWK.from_binary/1`, `JOSE.JWK.from_map/1`, `jose_jwk:from_binary/1` or `jose_jwk:from_map/1` on untrusted input.

## Fix

- Upgrade jose to `1.11.13` or later.
- Until upgraded, avoid parsing attacker-supplied JWKs through these functions, or rate-limit the endpoints that accept them.

## Timeline

- 2026-10-26T20:50:18+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-65631

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_