---
id: "CVE-2026-65628"
kind: "vulnerability"
aliases: ["CVE-2026-65628"]
title: "Elixir jose: mismatched JWK types cause endless loop and denial of service"
severity: "medium"
cvss: 5.9
epss: null
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["ecdh", "elixir", "erlang", "jose", "jwt", "package"]
not_affected_if: ["default-config", "no-external-peer-keys"]
published_at: "2026-10-26T20:17:58+00:00"
first_seen_at: "2026-10-26T20:50:17+00:00"
updated_at: "2026-10-26T20:51:49+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-65628", "first_seen_at": "2026-10-26T20:50:17+00:00"}]
---

# Elixir jose: mismatched JWK types cause endless loop and denial of service

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.

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

## How to check

- Run `mix deps | grep jose` or inspect `mix.lock` for the `jose` version in use
- 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
- Validate that the peer JWK's kty and curve match your own key before calling `JOSE.JWK.shared_secret`

## Timeline

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

## From the sources

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.

An 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.

This issue affects jose: from 1.5.0 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_