Nexus Repository 3 CVE-2026-14644

Exploitation requires: (1) an authenticated Nexus Repository 3 account with permission to manage privileges - this is not a default low-privileged user right, it must be explicitly delegated; (2) the target instance must be running under 'certain role configurations' as described in the CVE, meaning not all Nexus deployments are vulnerable even if an attacker holds privilege-management rights. What limits exploitation: the PR:L requirement means unauthenticated external attackers cannot exploit this directly; the role-configuration prerequisite means organizations using simple admin/non-admin role models without delegated privilege management are not in the vulnerable path; and the AV:N vector requires network reachability to the Nexus REST API, which in well-segmented environments may be restricted to internal networks. The specific role configuration that triggers the vulnerability is not detailed in available data - defenders should consult the vendor advisory for configuration-specific guidance.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N) yields a score of 8.6, reflecting a network-accessible, low-complexity privilege escalation requiring only a low-privileged authenticated account. However, the CVE description introduces a meaningful qualifier not captured in the provided AT:N metric: exploitation works only 'under certain role configurations,' which implies the attack does not succeed against all deployments or all authenticated users. This analyst assesses AT:P (attack requirement: specific role configuration must be present) as more precise than AT:N, and AC:H in CVSS 3.1 terms. No EPSS data was provided; no CISA KEV listing exists; no public exploit code has been confirmed. Absence of KEV does not mean low risk - this vulnerability is self-reported by Sonatype, suggesting it was discovered internally and patched proactively. The real-world priority is elevated for organizations running Nexus Repository 3 where any user account holds privilege-management delegation, such as team leads, DevOps engineers, or service accounts with scoped admin rights.

An attacker with a legitimate Nexus Repository 3 account that has been delegated privilege-management rights - for example, a CI/CD service account or a team-lead account with scoped admin access - sends a crafted REST API request to the privilege update endpoint, substituting an incompatible privilege type in the request body. If the target system's role configuration matches the vulnerable condition, the server processes the type-confused payload and promotes the attacker's account to full administrator, granting unrestricted read and write access to all repositories, credentials, and configurations. No public exploit code has been confirmed, but the vendor's self-disclosure and the straightforward REST API attack surface suggest a motivated actor with API documentation could independently develop a working exploit.