Nexus Repository 3 CVE-2026-17596

Exploitation requires two distinct conditions to both be met. First, the attacker must be authenticated to Nexus Repository 3 with an account that holds either the nexus:blobstores:create or nexus:blobstores:update permission - the CVSS 4.0 PR:L metric confirms this low-privilege authenticated prerequisite. Second, a separate victim user must navigate to the system health-check status page, confirmed by CVSS 4.0 UI:P (passive user interaction required). Exploitation is therefore limited by: (1) the attacker needing a valid account with specific blob store management rights, (2) the need for a victim to view the health-check page, and (3) the victim's browser having an active authenticated session. Default Nexus installations that restrict blob store permissions to administrators only significantly reduce the realistic attacker pool, as exploitation then requires a malicious or compromised admin account.

The vendor-assigned CVSS 4.0 score of 6.3 (Medium) reflects the real-world constraints accurately. AV:N/AC:L/AT:N confirm the attack is network-reachable with no special timing or race conditions, but PR:L requires the attacker to already hold a low-privileged authenticated account with specific blob store permissions - meaning this is not an unauthenticated or zero-effort attack. UI:P indicates the payload only fires when a victim user passively navigates to the health-check status page, adding a second dependency. The SC:H/SI:H on the subsequent system (victim browser session) is the most serious signal: if the victim is an administrator, the attacker can fully compromise that session. EPSS data was not provided in the input and cannot be assessed. KEV status is absent and no public POC exists, indicating this is currently theoretical or limited to internal exploitation. Overall priority is moderate: not a fire-drill, but warrants prompt patching given the potential for privilege escalation via admin session hijacking in multi-tenant or large team Nexus deployments.

An insider or a threat actor who has compromised an account with nexus:blobstores:create permission creates a new blob store with a name containing a JavaScript payload, such as a script that beacons session cookies to an attacker-controlled endpoint. When an administrator later opens the Nexus Repository 3 health-check status page - a routine operational task - the stored payload silently executes in their browser, delivering the administrator's session token to the attacker. No public proof-of-concept code has been identified at time of analysis, but the technique is well-understood and trivially reproducible by anyone with the required permissions.