CVE-2026-113368 in Nexus Repository
Summary
by MITRE • 11/04/2026
Sonatype Nexus Repository 3 does not check that a user account is authorized to access a repository before the repository is added as a member of a group repository. A user account that has signed in with valid credentials and holds the add or edit privilege on a group repository can add a repository that the account cannot read or browse, and then read the content of that repository through the group. The anonymous user can only do this if an administrator has explicitly granted it that privilege.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 11/04/2026
The vulnerability in Sonatype Nexus Repository 3 represents a critical authorization bypass within the artifact management infrastructure, specifically affecting how group repositories aggregate their member components. In standard operations, a group repository functions as a virtual container that aggregates content from multiple underlying physical or proxy repositories to provide a unified interface for clients. The security flaw arises during the configuration phase where an administrator or authorized user adds a new repository to this group structure. The system fails to perform a necessary access control check to verify whether the initiating user account possesses read permissions on the target repository being added as a member. This oversight creates a logical gap in the privilege enforcement mechanism, allowing users with write privileges for the group configuration but lacking direct read access to specific repositories to exploit this misconfiguration.
From a technical perspective, the core issue is an insecure direct object reference combined with insufficient authorization checks on resource modification operations. When a user account holds the add or edit privilege on a group repository, it can modify the list of member repositories without validating its own permissions against those members. Consequently, if such a user adds a private or restricted repository to their controlled group, they effectively create an indirect access path. By querying the group endpoint rather than the individual repository endpoint directly, the system serves up content from the newly added member because the group itself is authorized for that user, even though direct access to the underlying resource would be denied. This mechanism bypasses standard role-based access control policies designed to segregate sensitive artifacts based on project or team requirements.
The operational impact of this vulnerability is significant for organizations relying on Nexus Repository for secure software supply chain management. It allows authenticated users with moderate privileges to escalate their effective permissions, gaining unauthorized visibility into private repositories containing proprietary source code, licensed third-party components, or internal build artifacts. This exposure can lead to intellectual property theft and compliance violations regarding data privacy regulations such as GDPR or HIPAA if sensitive information is stored within the repository. Furthermore, it undermines the principle of least privilege by allowing users to access resources outside their designated scope without explicit administrative approval for those specific assets. The risk is mitigated slightly by the requirement that the anonymous user cannot exploit this unless an administrator explicitly grants them group modification privileges, but any authenticated insider threat or compromised account with standard developer rights can leverage this flaw.
This vulnerability aligns closely with CWE-862, which describes Missing Authorization, as the application fails to enforce access control rules on a specific resource during a state-changing operation. It also maps to MITRE ATT&CK technique T1078, Valid Accounts, where an attacker uses legitimate credentials to gain unauthorized access to resources by exploiting configuration flaws rather than breaking authentication mechanisms directly. To mitigate this risk, administrators should immediately apply the vendor-provided patches that enforce strict permission checks when adding repositories to groups. Additionally, organizations should review their role-based access control policies to ensure that users with group management privileges do not inadvertently hold excessive permissions over sensitive data stores. Implementing regular audits of repository configurations and monitoring for unusual aggregation patterns can further help detect any attempts to exploit this logical flaw before significant damage occurs.