CVE-2026-44015: 
Nginx UI vulnerability analysis and mitigation

CVE-2026-44015 is a Server-Side Request Forgery (SSRF) vulnerability in Nginx UI, a web-based management interface for the Nginx web server. Affecting versions 2.3.4 and earlier, it allows any authenticated user to create a malicious cluster node pointing to an arbitrary internal URL and then proxy API requests to that internal address via the X-Node-ID header. The vulnerability was published on May 12, 2026, with the security advisory originally published by the maintainer on April 22, 2026. It carries a CVSS v3.1 base score of 9.9 (Critical) per NVD, though the GitHub advisory rates it 8.5 (High) (GitHub Advisory, Red Hat CVE).

The root cause is CWE-918 (Server-Side Request Forgery), stemming from a lack of URL validation in the Proxy middleware (internal/middleware/proxy.go). When an API request includes an X-Node-ID header, the middleware looks up the corresponding cluster node's URL and blindly forwards the request to that address — with no allowlist, blocklist, or restriction against loopback addresses, private IP ranges, or cloud metadata endpoints. An attacker first reads the node_secret from GET /api/settings (accessible to any authenticated user), then creates a cluster node via POST /api/nodes with the url field set to an internal target (e.g., http://127.0.0.1:51820 or http://169.254.169.254/latest/meta-data/), and finally sends any API request with the X-Node-ID header set to the new node's ID to have the server proxy the request internally. A Python PoC automating these three steps is included in the security advisory (GitHub Advisory).

Successful exploitation allows an authenticated attacker to access internal services bound to localhost or private networks that are not externally reachable, including cloud instance metadata endpoints (AWS, GCP, Azure) to steal IAM credentials. Attackers can also conduct internal port scanning by creating nodes pointing to different internal IPs and ports, effectively bypassing network segmentation and host-based firewalls. When chained with a companion njs code injection vulnerability (separate advisory), this SSRF can be used to trigger internal-only Nginx endpoints and escalate to full remote code execution, impacting confidentiality, integrity, and availability of the host and connected internal systems (GitHub Advisory).

A public Python proof-of-concept exploit is available in the GitHub security advisory, demonstrating the full SSRF attack chain. Exploitation requires only low-privilege authenticated access to the Nginx UI instance and no user interaction. There is currently no evidence of in-the-wild exploitation, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is 0.028% (0.000280), indicating a low current probability of exploitation in the wild (GitHub Advisory, Red Hat CVE).

1. Authenticate: Obtain valid credentials for any user account on the target Nginx UI instance (version ≤ 2.3.4) and authenticate to retrieve a session token.
2. Retrieve node_secret: Send GET /api/settings with the Authorization header to extract the node.secret value from the JSON response — this is accessible to all authenticated users.
3. Create malicious cluster node: Send POST /api/nodes with a JSON body specifying an internal target URL (e.g., {"name": "ssrf", "url": "http://127.0.0.1:51820", "token": "<node_secret>", "enabled": true}). Record the id returned in the response.
4. Trigger SSRF: Send any API request (e.g., GET /api/settings) with the X-Node-ID header set to the created node's ID. The Proxy middleware forwards the request to the internal URL specified in step 3.
5. Receive internal response: The response body contains data from the internal service, not from Nginx UI itself — confirming access to the internal target.
6. Escalate (optional): Target cloud metadata endpoints (http://169.254.169.254/latest/meta-data/) to steal IAM credentials, or chain with the companion njs code injection advisory to achieve remote code execution on the host (GitHub Advisory).

• Network: Outbound connections from the Nginx UI process to loopback (127.0.0.1) or private IP ranges (RFC 1918) on unexpected ports; HTTP requests to cloud metadata IP 169.254.169.254 originating from the Nginx UI service.
• Logs: Nginx UI access logs showing POST /api/nodes requests creating nodes with internal or loopback URLs; subsequent API requests (e.g., GET /api/settings) carrying an X-Node-ID header from the same session.
• Application Behavior: Cluster node entries in the Nginx UI database with url fields pointing to 127.0.0.1, localhost, 169.254.169.254, or other internal addresses; unexpected node names such as ssrf or ssrf_node.
• Process: Unusual outbound TCP connections from the Nginx UI Go process to internal ports not associated with legitimate cluster nodes (GitHub Advisory).

Upgrade Nginx UI to version 2.3.5 or later, which addresses the lack of URL validation in the Proxy middleware. As interim workarounds: restrict access to the Nginx UI instance to trusted users only; implement network-level controls (firewall rules, egress filtering) to prevent the Nginx UI process from making outbound connections to internal IP ranges and metadata endpoints; and disable or restrict the cluster node creation API (POST /api/nodes) if multi-node clustering is not required. Monitor API logs for POST /api/nodes requests with internal URLs and API calls containing X-Node-ID headers targeting unexpected node IDs (GitHub Advisory, Red Hat CVE).

The vulnerability was reported by security researcher miffyaa and disclosed via the GitHub security advisory program. Red Hat has acknowledged the CVE and published a tracking entry. Community discussion has been limited, with some coverage on threat intelligence aggregators and a Bluesky post from cyberhub.blog. No major vendor statements or significant media coverage beyond standard vulnerability tracking have been observed (GitHub Advisory, Red Hat CVE).