Nexus Repository 3 CVE-2026-77124

Exploitation requires all of the following to be simultaneously true: (1) the attacker controls a valid Nexus Repository 3 account with the nx-script (script-execution) permission, corresponding to PR:H; (2) the administrator has explicitly set nexus.scripts.allowCreation=false as a hardening measure - instances without this flag set are not in the specific affected security state described; and (3) at least one Groovy script must have been created and stored on the instance prior to the flag being set, since the bypass enables execution of existing scripts only and does not permit creation of new ones. What limits exploitation: standard user accounts without the script-execution role cannot exploit this; the flag must have been deliberately enabled as a hardening action; and scripts must pre-exist on the instance. Default Nexus installations without the hardening flag are unaffected by the specific security-control bypass described, though they remain exposed to script-execution risks through other means.

The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:H/UI:N/VC:H/VI:H/VA:H) accurately captures the central tensions: network-reachable with low exploitation complexity once preconditions are met, but gated behind high-privilege credentials (PR:H) and a specific target condition (AT:P - the administrator must have already enabled the hardening flag and pre-existing scripts must be present). Real-world risk is consequently narrower than the raw impact metrics suggest: the bypass is only exploitable in hardened environments where the flag has been set, meaning default deployments without the flag are not in the specific affected state. The primary threat model is a privileged insider or attacker with compromised credentials undermining an administrator's deliberate hardening decision. No EPSS score is provided in the input data, and the absence of KEV listing indicates no confirmed in-the-wild exploitation at time of analysis. Even a mid-sized enterprise team that set nexus.scripts.allowCreation=false specifically to remove the scripting attack surface should treat this as urgent, since their expected security posture is not in effect until the patch is applied.

An attacker who has compromised or obtained a Nexus account holding the script-execution permission authenticates to the REST API and enumerates stored scripts via GET /service/rest/v1/script, then issues POST /service/rest/v1/script/{name}/run against a suitable pre-existing Groovy script - bypassing the administrator's expectation that nexus.scripts.allowCreation=false had disabled this capability. The Groovy script executes server-side with Nexus process privileges, enabling arbitrary command execution, exfiltration of stored credentials and artifact metadata, or lateral movement within the server environment. No public proof-of-concept code has been identified, but the scripting API mechanics are publicly documented in Sonatype's developer resources.