CVE-2026-75542: OAuth token exchange grants repository scopes for organizations the principal cannot access
Incorrect Authorization vulnerability in the OAuth token endpoint in hexpm hexpm allows an API key holding the repositories permission to read another organization's private packages.
When an API key is exchanged for a token through the OAuth clientcredentials grant, validatescopesagainstkey/2 in lib/hexpmweb/controllers/api/oauthcontroller.ex admits a requested scope whenever the key carries the repositories permission and the scope string begins with repository:. The organization name is never resolved against the principal, and expandrepositoriesscope/3 only rewrites the literal repositories scope, so an explicit repository:<name> passes through untouched. Both CDN edges authorize repository access from the token claim without querying the database, so the minted token is read access to that organization's private packages until it expires.
This issue affects hex.pm: from 2025-10-18 before 2026-08-24.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Update validate_scopes_against_key/2 so that requested scope strings beginning with "repository:" are validated against what the API key principal is actually allowed to access; the organization/repository name must be resolved against the principal, and expand_repositories_scope/3 must not allow an explicit repository:<name> to pass through unchanged.
hexpm (lib/hexpm_web/controllers/api/oauth_controller.ex) validate_scopes_against_key/2 scope validation for repository scopes = Only admit repository:<name> scopes when the API key’s repositories permission is for that same organization/repository principal (do not pass through an explicit repository:<name> scope untouched)
Event History
Frequently Asked Questions
What does an attacker need to exploit this issue?
The attacker needs an API key with the repositories permission and access to an OAuth client_credentials token exchange. They can request an explicit repository:<name> scope for another organization, without needing access to that organization.
Which deployments and configurations are affected?
hex.pm versions from 2025-10-18 through versions before 2026-08-24 are affected. The vulnerable path applies when API keys with the repositories permission are exchanged through the OAuth client_credentials grant.
What access does a successfully minted token provide?
The token provides read access to the targeted organization's private packages until the token expires. CDN edges authorize this access from the token claim and do not query the database.
What should be restricted if patching is not immediately possible?
Restrict or disable client_credentials exchanges for API keys carrying the repositories permission where possible. Treat any ability to request arbitrary repository:<name> scopes during token exchange as unsafe until the affected version is remediated.