nginx-ui CVE-2026-42221

Exploitation requires the nginx-ui instance to be in its first-run unconfigured state, after initial deployment but before the legitimate administrator completes the setup wizard via the /api/install endpoint. The vulnerability window opens when the nginx-ui service starts for the first time and closes permanently once any user successfully submits valid installation parameters. Network reachability to the nginx-ui web interface (typically TCP port 80, 443, or custom ports like 8080) from the attacker's position is required-exploitation succeeds against internet-facing deployments or internal instances accessible to the attacker. No authentication, credentials, or user interaction is required; the /api/install endpoint accepts requests from any source during this initialization phase. Attack complexity stems not from technical barriers but from timing: the attacker must reach the endpoint before legitimate operators, making this a race condition rather than a persistent flaw. Cloud deployments with public IP assignment before configuration, containerized instances with exposed ports during orchestration, or installations following documented setup guides that create exposure windows are most susceptible.

The CVSS 3.1 score of 8.1 (High) reflects substantial impact potential: network-accessible attack vector (AV:N), no privileges required (PR:N), no user interaction (UI:N), and high impact across confidentiality, integrity, and availability (C:H/I:H/A:H). However, attack complexity is HIGH (AC:H) due to the narrow exploitation window-the vulnerability only exists during initial deployment before legitimate configuration. This temporal constraint significantly reduces real-world risk compared to persistent authentication bypasses. No CISA KEV listing suggests this is not being exploited at scale, consistent with the time-sensitive nature requiring attackers to monitor for new nginx-ui deployments. EPSS score unavailable, limiting probabilistic risk assessment. The SSVC framework would categorize this as requiring specialized conditions (non-default state = fresh installation), with high technical impact but low automatable exploitation due to timing requirements. Priority depends heavily on organizational deployment practices: high risk for cloud environments with publicly exposed instances during provisioning, moderate risk for private networks with controlled deployment windows. The permanent nature of the takeover (attacker sets credentials that persist indefinitely) elevates severity once successfully exploited, but the pre-condition of catching a fresh installation before legitimate setup makes this a targeted threat rather than opportunistic scanning risk.

An attacker continuously scans cloud provider IP ranges for newly deployed nginx-ui instances listening on default ports (typically 80/443 or 8080). When detecting an unconfigured instance via fingerprinting responses, the attacker immediately sends a crafted POST request to /api/install containing their own email, username, and password before the legitimate administrator completes setup. The encrypted request bypasses no authentication checks and successfully creates the administrative account with attacker-controlled credentials. The legitimate operator, arriving minutes later, finds the instance already configured and either fails to notice the compromise or assumes a colleague completed setup. The attacker maintains persistent administrative access to the Nginx management interface, enabling web server reconfiguration, traffic interception, or pivot points into backend infrastructure.