CVE-2026-77122 in Nexus Repository
Summary
by MITRE • 09/02/2026
An authorization flaw in the REST API repository details endpoint (GET /service/rest/v1/repositories/{repositoryName}) in Sonatype Nexus Repository 3 allowed an account holding read or browse permission on a group repository to retrieve metadata for member repositories on which it held no direct permission, by requesting the endpoint directly for the member repository name. For proxy repositories, the disclosed metadata includes the configured remote URL, which may reveal internal upstream hostnames. This includes the anonymous user if it has been granted this permission; whether the anonymous user holds this permission depends on the role and permission configuration of the specific installation.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/02/2026
The vulnerability identified in Sonatype Nexus Repository 3 represents a critical authorization flaw within the REST API, specifically affecting the repository details endpoint located at GET /service/rest/v1/repositories/{repositoryName}. This issue stems from an improper implementation of access control checks that fail to validate whether the requesting user possesses direct permissions on individual member repositories when accessing information about group or proxy repositories. In a typical Nexus Repository 3 deployment, administrators organize artifacts into groups for easier management and distribution. These groups aggregate content from various underlying repository types, such as hosted, proxy, or component repositories. The security architecture relies on role-based access control to restrict visibility and modification rights based on user roles. However, the flaw allows an authenticated user with read or browse permissions on a group repository to bypass these restrictions by directly querying the REST API for metadata of specific member repositories that are part of that group but on which the user has no explicit permission.
From a technical perspective, this vulnerability is classified under CWE-269, Improper Privilege Escalation, and more specifically aligns with CWE-862, Missing Authorization. The attacker exploits the fact that the API endpoint does not perform sufficient checks to ensure that the requested repository name corresponds to one where the user has direct access rights. Instead of verifying permissions against each individual member repository within a group context, the system returns metadata if the user can access the parent group or if they have general read access to any part of the aggregation structure. This design oversight effectively bypasses the granular permission model intended by Nexus Repository administrators. The vulnerability is particularly dangerous because it allows for information disclosure without requiring administrative privileges, relying only on basic read access which may be granted broadly within an organization.
The operational impact of this flaw varies depending on the type of repository being accessed. For proxy repositories, the disclosed metadata includes the configured remote URL, which points to the upstream artifact source. This exposure can reveal internal hostnames or network topology details that were not intended for general users. In enterprise environments where Nexus Repository acts as a central hub connecting to private internal registries or sensitive external sources, such information leakage aids attackers in mapping the infrastructure and identifying potential targets for further attacks. For hosted repositories, while direct artifact download might still be blocked by separate permission checks on the actual content endpoints, the metadata exposure can reveal repository names, storage paths, and other structural details that assist in reconnaissance activities. If anonymous users are granted read or browse permissions to any group repository, this vulnerability allows unauthenticated access to sensitive configuration data, significantly expanding the attack surface.
This behavior is consistent with techniques observed in the MITRE ATT&CK framework under T1087, Account Discovery, and potentially T1592, Gather Victim Host Information. By enumerating available repositories and their configurations, an attacker can build a comprehensive map of the artifact management infrastructure. This intelligence gathering phase is often a precursor to more severe attacks such as supply chain compromise or data exfiltration. The ability to discover internal URLs also facilitates further exploitation by allowing attackers to target specific upstream services that may have weaker security postures than the Nexus instance itself.
Mitigation strategies should focus on both immediate remediation and long-term architectural improvements. Users of Sonatype Nexus Repository 3 are advised to apply the latest available patches provided by Sonatype, which address this authorization logic error in the REST API layer. In environments where patching is not immediately feasible, administrators can mitigate risk by restricting read or browse permissions for group repositories only to trusted users who require such access, rather than granting them broadly across teams. Additionally, reviewing and tightening anonymous user permissions is crucial; if anonymous access is enabled, it should be limited strictly to public-facing proxies that do not contain sensitive internal metadata. Regular audits of role-based access control policies can help ensure that the principle of least privilege is maintained, preventing users from accessing resources beyond their designated scope.