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

CVE-2026-42221 is an unauthenticated first-run installer vulnerability in Nginx UI, a web-based management interface for the Nginx web server. Affecting versions 2.0.0 through 2.3.5 (fixed in 2.3.8), the flaw allows any unauthenticated remote attacker to claim the initial administrator account during the first-run setup window by sending crafted requests to the publicly exposed /api/install endpoint. The vulnerability was published on April 27, 2026 by researcher R1ZZG0D and patched on April 21, 2026 in v2.3.8. NVD assigns a CVSS v3.1 base score of 9.8 (Critical), while the GitHub Advisory rates it 8.1 (High) due to a higher attack complexity assessment (Github Advisory, RedHat CVE).

The root cause is CWE-306 (Missing Authentication for Critical Function): both GET /api/install and POST /api/install are registered in the public API router (api/system/router.go) without the AuthRequired() middleware, making them accessible to any network caller. The install handler (api/system/install.go) only checks whether the instance is already installed (i.e., JwtSecret is empty and SkipInstallation is false) and whether the ten-minute post-startup window has elapsed — it performs no caller authentication. The request-encryption flow (POST /api/crypto/public_key returning an RSA public key, with payloads submitted as encrypted_params) only protects payload confidentiality in transit and does not verify the requester's identity. An attacker who submits attacker-controlled credentials to POST /api/install causes the handler to overwrite user ID 1's username and password hash (api/system/install.go:93-97), permanently claiming the privileged account that internal/kernel/init_user.go guarantees exists (Github Advisory).

Successful exploitation results in complete takeover of the Nginx UI instance: the attacker sets the administrator email, username, and password before the legitimate operator can, locking out the rightful owner permanently. Because Nginx UI is an administrative interface for Nginx and host-management features, a compromised admin account enables unauthorized Nginx configuration changes, TLS certificate management abuse, backup manipulation, and service disruption. This can extend to broader operational compromise of all services managed through the Nginx UI instance (Github Advisory).

A detailed proof-of-concept (PoC) with step-by-step HTTP reproduction instructions is publicly available in the GitHub Security Advisory, including specific endpoints, request sequences, and expected responses (Github Advisory). Feedly threat intelligence confirms the exploit is classified as a real, high-confidence PoC. The EPSS score is approximately 0.085–0.104% (28th percentile), indicating a relatively low but non-negligible probability of exploitation in the wild within 30 days. No in-the-wild exploitation or threat actor attribution has been reported as of the time of this report, and the vulnerability is not listed in the CISA KEV catalog. Exploitation is constrained to the ten-minute post-startup window on fresh, uninitialized instances reachable over the network.

1. Reconnaissance: Identify internet-facing Nginx UI instances (versions 2.0.0–2.3.5) using tools like Shodan or Censys, or by directly probing the /api/install endpoint.
2. Confirm vulnerable state: Send GET /api/install to the target. A response of {"lock": false, "timeout": false} confirms the instance is fresh, uninitialized, and within the ten-minute setup window.
3. Obtain RSA public key: Send POST /api/crypto/public_key (no authentication required) to retrieve the server's RSA public key used for payload encryption.
4. Encrypt attacker credentials: Construct the JSON payload {"email": "attacker@example.com", "username": "attacker", "password": "Password12345"}, encrypt it with the obtained RSA public key, and base64-encode the ciphertext.
5. Claim the admin account: Submit the encrypted payload to POST /api/install as {"encrypted_params": "<base64-ciphertext>"}. A {"message": "ok"} response confirms success.
6. Verify takeover: Re-request GET /api/install and observe {"lock": true, "timeout": false}, confirming the instance is now initialized under attacker control. Optionally verify by querying the SQLite database: sqlite3 database.db 'select id,name,length(password) from users where id=1;' — expected output: 1|attacker|60.
7. Exploit admin access: Log in to Nginx UI with the attacker-set credentials and leverage full administrative control to modify Nginx configurations, manage certificates, or pivot to the underlying host (Github Advisory).

• Network: Unexpected GET /api/install requests from external IP addresses shortly after service startup; POST /api/crypto/public_key requests from untrusted sources; POST /api/install requests from IPs other than the legitimate administrator's.
• Logs: Nginx UI access logs showing the sequence GET /api/install → POST /api/crypto/public_key → POST /api/install from a single external IP within a short timeframe; log entries showing {"message": "ok"} response to POST /api/install from an unexpected source.
• File System / Database: SQLite database (database.db) showing user ID 1 with an unexpected username or a recently changed password hash; length(password) of 60 for user ID 1 set at an unexpected time (select id, name, length(password) from users where id=1;).
• Application State: GET /api/install returning {"lock": true} before the legitimate operator completed setup, indicating the installation window was claimed by an unauthorized party (Github Advisory).

Upgrade Nginx UI to version 2.3.8 or later, which hardens the first-run installation flow (commit 25dea9f62) (v2.3.8 Release). As an interim measure on affected versions (2.0.0–2.3.5), restrict network access to the Nginx UI service to trusted networks only using firewall rules, or take the service offline until it can be upgraded. Ensure the initial administrator account is claimed by the legitimate operator immediately upon deployment, before the service is exposed to untrusted networks. The advisory also recommends that future versions require a single-use bootstrap secret for installation and restrict the install endpoint to loopback by default (Github Advisory).

Heise Online covered the vulnerability with an article titled "Critical security vulnerability in Nginx UI closed again," noting it as a recurring security concern for the project. The vulnerability was also discussed on Bluesky and tracked by multiple vulnerability intelligence platforms including VulnDB, CVEFeed, and INCIBE-CERT. The Nginx UI project (11.2k GitHub stars) received community attention given the severity of the admin takeover scenario (Heise Article).