An API key created with read‑only permissions (domain "api", resource "read") can be abused when exchanged via the OAuth client_credentials Grant. The server’s scope validation ignores the resource qualifier, resulting in a JWT that carries the broad "api" scope instead of the expected limited "api:read" scope. The incorrectly scoped token is then treated as a full‑access token, allowing an attacker to create new API keys with unrestricted permissions, perform write operations such as publishing or retiring packages, and potentially compromise the entire Hex.pm ecosystem. This flaw is a classic privilege escalation stemming from improper scope enforcement (CWE‑863).

The vulnerability affects Hex.pm, the Elixir-based package manager powered by the hexpm:hexpm repository. It is present in all commits from 71829cb6f6559bcceb1ef4e43a2fb8cdd3af654b up to, but excluding, commit 71c127afebb7ed7cc637eb231b98feb802d62999. The affected components are the OAuth controller logic within the Hex.pm web application.

With a CVSS score of 7 and an EPSS score of less than 1 %, the exploit likelihood is considered low but non‑zero, and the vulnerability is currently not listed in CISA’s KEV catalog. The attack requires the attacker to possess a victim’s read‑only API key and a valid two‑factor authentication code for that account. Once those credentials are in hand, the attacker can trigger the client_credentials flow, receive a mis‑scoped JWT, and generate a new full‑access API key that does not expire by default. The risk is thus confined to accounts for which the attacker can procure both basic credential and 2FA, but the impact of such a token is system‑wide, enabling arbitrary package modifications and potential compromise of all dependent services.