Nginx UI CVE-2026-44015

Requires an authenticated Nginx UI account (CVSS PR:L; the advisory states any authenticated user suffices) and that the attacker can reach GET /api/settings to obtain node_secret and POST /api/nodes to create a cluster node - both described as accessible to authenticated users with no special non-default configuration. The cluster Proxy middleware performs no validation or allowlisting of the node URL, so no feature needs to be specially enabled. The main limiting factor is authentication (not unauthenticated); no user interaction is needed (UI:N), and exploitation affects Nginx UI 2.3.4 and earlier. No vendor-fixed version is available, so the evidence provides no patch to apply as a mitigation.

Signals diverge sharply. The input CVSS is 9.9 with vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, and the vuln.today decision label is act_now, yet EPSS is only 0.03% (8th percentile), there is no CISA KEV listing, and SSVC rates Exploitation as poc, Automatable as no, and Technical Impact as only partial. So this is not confirmed widespread exploitation - the act_now label and 9.9 score are driven by the critical technical outcome and the fact that the vendor advisory explicitly chains this SSRF with a companion njs code-injection advisory to complete an RCE path, not by observed mass exploitation. The CVSS vector contains PR:L, so exploitation is authenticated (any authenticated user, per the advisory), which meaningfully limits exposure compared to a fully unauthenticated flaw; SSVC Automatable:no is consistent with that multi-step, authenticated prerequisite. The partial SSVC technical impact somewhat contrasts with the C:H/I:H/A:H and S:C in the supplied vector. Treat this as a genuine high priority for any internet-exposed or multi-tenant Nginx UI instance - low EPSS reflects limited current scanning/targeting, not low severity, and it should not be read as safe. A key aggravating factor is that the evidence states the package is not yet patched, so no vendor fix version exists to apply.

An authenticated Nginx UI user reads the node_secret from GET /api/settings, creates a cluster node via POST /api/nodes pointing at an internal URL (e.g. http://127.0.0.1 or the cloud metadata endpoint 169.254.169.254), then replays an API request carrying the X-Node-ID header so the Proxy middleware forwards it to that internal address. This lets the attacker reach localhost/internal-only services and steal cloud IAM credentials from the metadata service. The GHSA advisory includes a working Python PoC demonstrating these exact steps.