Nexus Repository 3 CVE-2026-17601

The attacker must be authenticated to Nexus Repository 3 with an account that holds the 'update privilege definitions' permission - this is the single specific precondition confirmed by the description and reflected in AT:P and PR:L in the CVSS 4.0 vector. Additionally, the attacker's own role must already have at least one wildcard-type privilege assigned to it, as the attack vector is modification of an existing wildcard privilege definition rather than creation of a new one. Exploitation is further limited to Nexus Repository 3 deployments (not version 2.x per CPE). What limits exploitation: the 'update privilege definitions' permission is a non-default, deliberate grant - it is not part of a standard read-only or developer role. Organizations that follow least-privilege in their Nexus RBAC configuration and do not delegate privilege editing to non-administrators are not exposed to this path. There is no evidence of exploitation without this precondition, and no non-default configuration beyond having this permission is required.

The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:N) scores 8.9, reflecting a network-accessible flaw requiring low privileges and no user interaction, but with a specific attack requirement (AT:P) - the attacker must already hold the 'update privilege definitions' permission. This is a meaningful precondition that limits the exposed population relative to a typical PR:L flaw. However, the impact metrics (VC:H/VI:H/VA:H/SC:H/SI:H) reflect the devastating blast radius of full admin takeover in a repository manager: complete control over all hosted artifacts, credentials, and deployment pipelines, with high subsequent-system impact (SC:H/SI:H) because CI/CD consumers that pull from Nexus inherit whatever the attacker injects. No EPSS data was provided, and the vulnerability is not listed in CISA KEV, so widespread automated exploitation is not confirmed. No POC has been identified at time of analysis. The real-world risk is high for organizations where delegated privilege administration is practiced - granting the 'update privilege definitions' right is a routine operational action in large deployments, and affected users may not anticipate that it implies the ability to escalate to root. The AT:P precondition is the primary limiting factor.

An attacker operating under a Nexus account that has been granted the 'update privilege definitions' permission - for example, a developer with delegated repository administration rights - identifies a wildcard privilege already assigned to their own role and edits its pattern to match all repository paths and all actions. With no additional approval step triggered, the system silently accepts the change, and the attacker's existing role now encompasses full administrative access. The attacker can then create new admin accounts, exfiltrate all hosted package artifacts, or inject malicious packages into repositories consumed by organizational CI/CD pipelines.