CVE-2026-75542 in hexpm
Summary
by MITRE • 08/24/2026
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 client_credentials grant, validate_scopes_against_key/2 in lib/hexpm_web/controllers/api/oauth_controller.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 expand_repositories_scope/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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/24/2026
The vulnerability identified in Hex.pm represents a critical failure in authorization logic within the OAuth token endpoint, specifically affecting the handling of API keys with repository permissions. This flaw allows an attacker possessing an API key scoped to one organization's repositories to access private packages belonging to entirely different organizations. The root cause lies in the insufficient validation of requested scopes against the actual capabilities and ownership associated with the authenticated principal during the client_credentials grant flow. When a request is made for a token, the system validates whether the provided API key possesses the broad repositories permission but fails to verify that the specific repository name included in the scope actually belongs to the organization owning that API key. This oversight creates a significant gap between the intended access control policy and its actual enforcement, leading to unauthorized data exposure across organizational boundaries within the package management ecosystem.
Technically, the flaw resides in the validation logic implemented in the lib/hexpm_web/controllers/api/oauth_controller.ex file, specifically within the validate_scopes_against_key/2 function. The code checks if the API key holds the repositories permission and whether the requested scope string begins with repository:. If these conditions are met, the system admits the request without further scrutiny of the organization name contained in that scope string. Furthermore, the expand_repositories_scope/3 helper function only rewrites literal scopes matching a specific pattern but does not resolve or validate the actual ownership of the named repositories against the principal's identity. Consequently, an explicit repository:<name> parameter is passed through to the token generation process untouched and unvalidated by any database lookup that would confirm organizational affiliation. This means the system trusts the client-supplied scope name implicitly rather than deriving it from verified permissions associated with the API key owner.
The operational impact of this vulnerability is severe, as it results in the issuance of OAuth tokens that grant read access to private packages outside the authorized organization's boundary. These tokens are utilized by CDN edges which authorize repository access based solely on the token claims without performing additional database queries to verify current permissions or ownership at request time. Therefore, once a malicious actor obtains such an improperly scoped token through legitimate authentication mechanisms using their own API key, they can immediately download private source code, metadata, and other sensitive artifacts from any organization's private repositories until the token expires. This breach of confidentiality undermines the trust model of Hex.pm, where organizations rely on strict isolation to protect proprietary software assets and intellectual property from competitors or unauthorized third parties.
This issue is classified under CWE-269: Improper Authorization, as it involves a failure to enforce proper access controls for an actor interacting with system components within their permitted security context. In terms of the MITRE ATT&CK framework, this vulnerability facilitates Initial Access and Collection techniques where adversaries leverage valid credentials or tokens to move laterally and gather sensitive data from remote systems without detection by standard perimeter defenses that rely on token validity rather than granular permission verification. The attack vector is primarily network-based with low complexity, requiring only a valid API key for one organization and knowledge of another organization's private repository name to exploit the flaw effectively.
Mitigation strategies must focus on correcting the authorization logic within the OAuth controller to ensure strict validation of scope ownership. Developers should modify the validate_scopes_against_key/2 function to resolve the requested repository names against the database and verify that each named repository is explicitly owned by or accessible to the principal associated with the API key, rather than relying solely on a broad repositories permission flag. Additionally, the expand_repositories_scope/3 logic must be updated to enforce these ownership checks before rewriting scopes. To further reduce risk, implementing short-lived tokens and enforcing stricter scope granularity at the CDN edge level can limit the window of exposure if such invalid tokens are issued. Regular security audits focusing on OAuth implementation details and continuous monitoring for anomalous access patterns across organizational boundaries will also help in detecting potential exploitation attempts early.