Nexus Repository 3 EUVD-2026-102155

Requires an authenticated Nexus Repository 3 account that already holds the 'role create' OR 'role update' permission (PR:L); a fully anonymous or ordinary unprivileged user cannot trigger it. Given that prerequisite, the account can grant roles and privileges it does not itself hold, escalating up to full administrative access. The exploitation-limiting factor is this delegated permission gate - environments that restrict role-management capabilities to trusted administrators have a much smaller exposure, whereas deployments that delegate role creation/update to project or team leads are directly at risk. No end-user interaction and no special non-default configuration beyond having granted the role-management permission are required.

This is a credible, above-average-priority vulnerability but not an emergency. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H) scores 8.7 (High) and is internally consistent with the description: a network-reachable, low-complexity, authenticated (PR:L) flaw yielding high confidentiality, integrity and availability impact via full administrative takeover, with no subsequent-system scope change (SC:N/SI:N/SA:N). The key limiting signal is PR:L - exploitation is NOT available to anonymous attackers; it requires an account already holding the delegated 'role create' or 'role update' permission, which materially narrows the realistic attacker population to semi-trusted insiders or compromised delegated-admin accounts. No EPSS score, no CISA KEV listing, and no public POC were provided, so there is no evidence of active or at-scale exploitation at time of analysis - the risk is driven by severity-of-outcome (privilege escalation to full admin) rather than by demonstrated exploitation likelihood. The CWE-862 (Missing Authorization) classification aligns with the described broken access-control behavior; note the input 'Authentication Bypass' tag is a mischaracterization, since the flaw is an authenticated privilege-escalation issue, not a bypass of authentication. A patch is available (Nexus Repository 3.97.0), which should anchor remediation: this is a prioritize-and-patch item, especially where role-management permissions are delegated broadly.

A user who has been granted the 'role create' or 'role update' permission in Nexus Repository 3 - for example a team lead or delegated project administrator - crafts a role or privilege assignment that includes capabilities their own account does not possess. By granting those elevated privileges to themselves or a controlled account, they escalate from limited delegated access up to full administrative control over the repository manager. No public exploit code was identified at time of analysis, and exploitation is gated by already holding the role-management permission.