CVE-2026-77125 in Nexus Repository
Summary
by MITRE • 09/02/2026
A vulnerability was identified in Sonatype Nexus Repository 3 in which two blobstore group management REST API endpoints did not correctly enforce the intended authorization check. A user granted only the nexus:blobstores:create permission could invoke these endpoints to convert an existing blobstore into a group blobstore, an action that should require the nexus:blobstores:update permission instead. This could result in unauthorized modification of blobstore configuration without administrator approval. The nexus:blobstores:create permission is a named permission that must be explicitly granted by an administrator; it is not held by default.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/02/2026
A critical authorization bypass vulnerability has been identified within Sonatype Nexus Repository 3, specifically affecting the REST API endpoints responsible for managing blobstore groups. This flaw stems from an improper implementation of access control checks on two specific endpoints designed to convert existing standalone blobstores into group blobstores. The core technical deficiency lies in the fact that these operations incorrectly validate against the nexus:blobstores:create permission rather than requiring the more restrictive nexus:blobstores:update permission. In a properly secured system, converting a blobstore from one type to another constitutes an update operation on its configuration and metadata, which logically falls under the scope of modification rights rather than creation rights. By accepting requests authenticated with only create privileges, the application fails to enforce the principle of least privilege, allowing users with limited scopes to perform administrative-level modifications that should be reserved for higher-privileged roles or require explicit administrator approval.
The operational impact of this vulnerability is significant as it allows an attacker who has been granted the nexus:blobstores:create permission to manipulate the underlying storage configuration without proper authorization. Blobstores are fundamental components in Nexus Repository, serving as the physical location where artifacts and metadata are stored. An unauthorized conversion of a blobstore into a group blobstore can disrupt repository operations, potentially leading to data inconsistency or service disruption depending on how the misconfigured blobgroup is subsequently utilized by other services or users. Furthermore, this capability could be leveraged in conjunction with other vulnerabilities to escalate privileges within the application environment, as it effectively bypasses the intended administrative controls designed to prevent unauthorized structural changes to the repository infrastructure.
From a classification perspective, this vulnerability aligns closely with CWE-269, which denotes Improper Privilege Management, specifically highlighting cases where an actor is granted permissions that exceed their actual role or intent. Additionally, the exploitation technique relates to ATT&CK tactic T1078, Valid Accounts, as it relies on legitimate but insufficiently scoped credentials being used to perform actions outside of their intended boundaries. The vulnerability underscores a common architectural oversight in REST API design where permission checks are mapped too broadly to resource creation rather than specific action types such as update or delete operations.
To mitigate this risk, administrators should immediately review and restrict the assignment of the nexus:blobstores:create permission within Nexus Repository 3 instances. It is crucial to ensure that only users who genuinely require the ability to create new blobstore definitions are granted this role, while those needing to modify existing configurations must be assigned the appropriate update permissions with corresponding oversight mechanisms. Sonatype has addressed this issue in subsequent security releases of Nexus Repository Manager 3, and upgrading to a patched version is the most effective remediation strategy. Until an upgrade can be performed, organizations should implement strict network-level access controls for the affected API endpoints and monitor audit logs for any unusual attempts to convert blobstores using create-scoped accounts. Regular audits of user roles and permissions are also recommended to ensure that privilege assignments remain aligned with current operational requirements and security policies.