Nexus Repository 3 CVE-2026-17597

Exploitation requires an authenticated user account explicitly holding the nexus:settings:update permission, which in standard Nexus Repository deployments is restricted to administrator-level roles. The vulnerable entry point is specifically the email configuration test/verification endpoint - standard repository users, anonymous users, and accounts without the settings update permission cannot reach or trigger this functionality. No special non-default Nexus configuration is required beyond the presence of a user with the relevant permission; the email verification feature is a standard component of the Nexus administrator UI. What limits exploitation: the high-privilege prerequisite (PR:H per the CVSS 4.0 vector) means only administrators or users explicitly granted elevated settings permissions can abuse this flaw; unauthenticated access and standard developer/deployer accounts are not affected. The impact is further bounded to network topology inference - no direct data exfiltration from the Nexus system or the probed hosts is possible via this vector alone.

The vendor-provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:N/VA:N/SC:L/SI:N/SA:N) scoring 5.1 accurately reflects the constrained impact profile: no data is directly exfiltrated from the vulnerable system (VC/VI/VA:N), and only low subsequent-system confidentiality is achievable (SC:L) through network topology inference. The high-privilege prerequisite (PR:H) is the dominant risk-limiting factor - exploitation requires a user explicitly granted the nexus:settings:update permission, which is typically scoped to Nexus administrators. EPSS data was not provided, preventing probabilistic exploitation assessment. The vulnerability is absent from the CISA KEV catalog and no public exploit code has been identified, further reducing the likelihood of opportunistic mass exploitation. The realistic threat is an insider threat or compromised administrator credential scenario, where an adversary with existing admin access uses this SSRF to enumerate internal services reachable from the Nexus host - particularly relevant in environments where Nexus has broad internal network access (e.g., adjacent to CI/CD pipelines, internal registries, or database hosts). This is a moderate-priority issue for most deployments; organizations with strict internal network segmentation may consider the risk lower, while those where Nexus has wide LAN access should treat this as a meaningful reconnaissance primitive.

An attacker who possesses or has compromised an administrator account with the nexus:settings:update permission navigates to the Nexus email configuration page and iteratively submits crafted host and port combinations - such as internal RFC 1918 addresses and common service ports (22, 3306, 6379) - to the email test endpoint. The server attempts outbound TCP connections to each target and returns differing error responses based on whether the port is open, closed, or filtered, allowing the attacker to systematically map internal services reachable from the Nexus host. No public exploit code has been identified at time of analysis, but the technique is mechanically straightforward and well-understood within the SSRF research community.