CVE-2026-77124 in Nexus Repository
Summary
by MITRE • 09/02/2026
In affected versions of Nexus Repository 3, the script execution endpoint (POST /service/rest/v1/script/{name}/run) did not verify whether script execution had been administratively disabled. An account holding script-execution permission could continue to run previously-created scripts even after an administrator set nexus.scripts.allowCreation=false, undermining the expectation that this setting fully blocks script execution.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/02/2026
The vulnerability identified in Nexus Repository 3 represents a critical failure in access control logic within the application's scripting subsystem. Specifically, the endpoint responsible for executing stored Groovy scripts, located at POST /service/rest/v1/script/{name}/run, fails to perform an adequate check against the global administrative configuration that disables script execution. This flaw allows users with specific permissions related to script creation and management to bypass security restrictions intended by system administrators. The core issue lies in the sequence of validation checks performed during a request; while the application correctly prevents the creation or modification of new scripts when nexus.scripts.allowCreation is set to false, it neglects to verify this same flag before executing an existing script stored on disk. This inconsistency creates a significant gap between the intended security posture and the actual runtime behavior of the software.
From a technical perspective, this vulnerability falls under CWE-284 Improper Access Control, as the application fails to enforce proper restrictions on authorized users regarding specific actions. The attacker does not need external authentication bypass or privilege escalation in the traditional sense; rather, they exploit an existing permission set that was granted legitimately but is no longer valid due to a configuration change. This scenario aligns with MITRE ATT&CK technique T1059 Command and Scripting Interpreter, where adversaries use scripts like Groovy to execute arbitrary commands on the underlying host system. Since Nexus Repository 3 typically runs as a service with elevated privileges relative to standard user accounts, successful exploitation can lead to remote code execution (RCE) on the server hosting the repository manager. This capability allows an attacker to read sensitive configuration files, exfiltrate credentials stored within the nexus database, or pivot further into the internal network depending on the deployment environment and containerization settings.
The operational impact of this vulnerability is severe because it undermines the principle of least privilege when security configurations are updated dynamically. Administrators often disable script execution as a hardening measure to reduce the attack surface, assuming that no scripts can be run once this setting is applied. However, due to this flaw, any pre-existing scripts remain executable by users who retained their original permissions. This means that even after an organization identifies the risk and applies the configuration fix, legacy scripts continue to pose a threat until they are manually deleted or the affected user accounts have their script-related privileges revoked. In environments where multiple teams share access to Nexus Repository 3, this can lead to unauthorized data exposure or system compromise if any team member retains write access to scripts but not administrative rights.
Mitigation strategies must address both the immediate technical flaw and broader security hygiene practices. The primary remediation is to upgrade Nexus Repository 3 to a version where the script execution endpoint correctly validates the nexus.scripts.allowCreation flag before proceeding with execution. For organizations unable to patch immediately, it is imperative to manually review all existing scripts in the repository and delete any that are not strictly necessary for business operations. Additionally, administrators should audit user roles and permissions, ensuring that no non-administrative users retain script creation or management privileges if script execution has been disabled globally. Implementing strict role-based access control (RBAC) policies where only a minimal set of trusted administrators can manage scripts will further reduce the risk surface. Regular security audits and configuration reviews should be conducted to ensure that administrative settings are consistently enforced across all API endpoints, preventing similar logic flaws in other subsystems from being exploited.