Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-17597

CVE-2026-17597: Nexus Repository 3 SSRF Vulnerability

CVE-2026-17597 is a Server-Side Request Forgery vulnerability in Nexus Repository 3 that allows attackers to probe internal networks. This article covers the technical details, affected versions, security impact, and mitigation.

Published:

CVE-2026-17597 Overview

CVE-2026-17597 is a Server-Side Request Forgery (SSRF) vulnerability [CWE-918] in Sonatype Nexus Repository 3. The flaw resides in the email configuration verification feature. An authenticated user holding the nexus:settings:update permission can submit arbitrary host and port values to the email test endpoint. The server then attempts outbound connections to attacker-specified addresses, including internal or otherwise restricted network resources. Response variations allow the attacker to infer whether internal hosts and ports are reachable. The issue affects Nexus Repository 3 Community Edition and Pro versions up to and including 3.94.1, and is fixed in version 3.95.0.

Critical Impact

An authenticated administrator can weaponize the email verification endpoint to probe internal network topology from the Nexus server.

Affected Products

  • Sonatype Nexus Repository 3 Community Edition versions up to and including 3.94.1
  • Sonatype Nexus Repository 3 Pro versions up to and including 3.94.1
  • Fixed release: Sonatype Nexus Repository 3.95.0

Discovery Timeline

  • 2026-08-07 - CVE-2026-17597 published to NVD
  • 2026-08-07 - Last updated in NVD database

Technical Details for CVE-2026-17597

Vulnerability Analysis

Nexus Repository exposes an email configuration verification endpoint that allows administrators to test Simple Mail Transfer Protocol (SMTP) connectivity before saving mail server settings. The endpoint accepts user-supplied host and port parameters and attempts a network connection using those values. The application does not restrict the destination to legitimate mail servers or to an allowlist of external addresses.

An attacker who already possesses the nexus:settings:update permission can submit crafted values that point at internal IP ranges, cloud metadata endpoints, or loopback services. The server initiates the connection from its own network position, bypassing perimeter controls that normally isolate internal infrastructure. Differences in error responses, connection timing, or returned status messages reveal whether the target host and port accept connections, enabling network reconnaissance from a trusted internal vantage point.

Root Cause

The root cause is missing destination validation on the SMTP verification handler. The endpoint trusts user-supplied network parameters without enforcing an allowlist, blocking private address ranges, or filtering link-local metadata addresses. This matches the pattern described in CWE-918: Server-Side Request Forgery.

Attack Vector

The attack requires network access to the Nexus web interface and valid credentials for an account with the nexus:settings:update permission. The attacker sends repeated verification requests, iterating through internal IP addresses and common service ports. By observing timing and response differentials, the attacker maps reachable internal services such as databases, orchestration APIs, or cloud instance metadata endpoints. No exploit code is required beyond scripting the verification API. See the Sonatype Support Article for advisory details.

Detection Methods for CVE-2026-17597

Indicators of Compromise

  • Repeated calls to the Nexus email verification or SMTP test endpoint from a single administrative account within a short interval.
  • Outbound TCP connection attempts from the Nexus server to RFC1918 addresses, 127.0.0.0/8, or cloud metadata IPs such as 169.254.169.254.
  • Nexus audit log entries showing nexus:settings:update actions immediately followed by SMTP configuration test requests targeting non-mail ports.

Detection Strategies

  • Inspect Nexus access logs for POST requests to the email verification endpoint containing non-standard SMTP ports such as 22, 80, 443, 3306, 6379, or 8080.
  • Correlate application-layer logs with egress firewall logs to identify SMTP test actions that trigger connections to internal subnets.
  • Alert on any administrative changes to email settings that specify hostnames resolving to private or reserved address space.

Monitoring Recommendations

  • Enable and forward Nexus audit logs to a central log platform for retention and correlation.
  • Baseline expected outbound destinations from the Nexus host and alert on deviations.
  • Monitor privileged role assignments granting the nexus:settings:update permission and review account activity for these users.

How to Mitigate CVE-2026-17597

Immediate Actions Required

  • Upgrade Nexus Repository 3 to version 3.95.0 or later, as documented in the Sonatype Nexus 3.95.0 Release Notes.
  • Audit all accounts granted the nexus:settings:update permission and revoke it where not required.
  • Review recent email configuration test activity in audit logs for signs of internal network probing.

Patch Information

Sonatype fixed the SSRF in Nexus Repository 3.95.0. The patched release adds validation on the email verification endpoint so that connection attempts are constrained appropriately. Administrators running any release from 3.94.1 or earlier should plan an upgrade. Full release details are published in the Sonatype Nexus Release Notes.

Workarounds

  • Restrict egress network traffic from the Nexus server so it can only reach approved SMTP relays and required external services.
  • Place Nexus behind an egress proxy that enforces destination allowlisting and blocks connections to RFC1918 and cloud metadata ranges.
  • Limit the nexus:settings:update permission to a small set of tightly monitored administrator accounts until the upgrade is applied.
bash
# Example iptables egress restriction limiting Nexus host to an SMTP relay
# Replace 10.0.0.25 with your approved SMTP server address
iptables -A OUTPUT -o eth0 -p tcp -d 10.0.0.25 --dport 587 -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp -d 169.254.169.254 -j DROP
iptables -A OUTPUT -o eth0 -p tcp -d 10.0.0.0/8 -j DROP
iptables -A OUTPUT -o eth0 -p tcp -d 172.16.0.0/12 -j DROP
iptables -A OUTPUT -o eth0 -p tcp -d 192.168.0.0/16 -j DROP

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.