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

CVE-2026-42222 is an unauthenticated bootstrap takeover vulnerability in Nginx UI, a web-based management interface for the Nginx web server. Affecting version 2.3.5, the flaw allows any unauthenticated remote attacker to claim a fresh instance by submitting attacker-controlled credentials and application secrets via the POST /api/install endpoint during the initial 10-minute setup window. The vulnerability was first published by the National Vulnerability Database on May 4, 2026, and added to the GitHub Advisory Database on May 6, 2026. It carries a CVSS v3.1 base score of 8.1 (High) per the GitHub advisory (GHSA-mxqh-q9h6-v8pq), though Feedly also reports an alternative score of 9.8 (Critical) based on a lower attack complexity assessment (GitHub Advisory, Security Advisory).

The root cause is classified as CWE-284 (Improper Access Control) and CWE-306 (Missing Authentication for Critical Function). The POST /api/install endpoint is exposed without any authentication requirement when the nginx-ui instance is in its uninitialized first-run state, accepting attacker-supplied bootstrap data including the JWT secret, node secret, certificate email, and initial administrator credentials. An attacker first queries GET /api/install to confirm the instance is unclaimed ({"lock":false,"timeout":false}), retrieves the server's RSA public key from /api/crypto/public_key, encrypts their chosen credentials using PKCS#1 padding, and submits them via POST /api/install — effectively defining all application trust material before the legitimate operator can. The advisory also notes that OPTIONS /api/install returned Access-Control-Allow-Origin: *, which may enable browser-assisted cross-origin exploitation in some deployment layouts (GitHub Advisory, Security Advisory).

Successful exploitation results in complete administrative takeover of the nginx-ui instance: the attacker sets the administrator account credentials, the JWT secret, and the node secret, locking out the legitimate operator entirely. Because the attacker defines the application's trust material rather than merely guessing defaults, the compromise is more severe than a default-credential issue — all subsequent authentication tokens and node communications are under attacker control. This grants full control over Nginx configuration, potentially enabling web traffic manipulation, service disruption, or use of the compromised server as a pivot point within the network (Security Advisory, GitHub Advisory).

A complete, standalone bash PoC exploit is publicly available in the GitHub security advisory, requiring only bash, curl, and openssl to execute against a live target. The exploit has been confirmed to work against nginx-ui v2.3.5 (Docker image uozi/nginx-ui@sha256:d73343e3009c9b558129a2be0cacd6c2c57ed8006a5871873b874b812e612e5a). The EPSS score is approximately 0.041–0.059%, and there is no current evidence of in-the-wild exploitation or CISA KEV catalog listing. No threat actor attribution has been reported (GitHub Advisory, Security Advisory).

1. Reconnaissance: Identify internet-facing or LAN-accessible nginx-ui instances running version 2.3.5 that are in their initial uninitialized state (e.g., newly deployed Docker containers, fresh installs, or rebuilt environments).
2. Confirm uninitialized state: Send GET /api/install to the target. A response of {"lock":false,"timeout":false} confirms the instance has not yet been configured and is exploitable.
3. Retrieve server RSA public key: Send a POST request to /api/crypto/public_key with a JSON body containing a timestamp and fingerprint to obtain the server's RSA public key used for encrypting bootstrap parameters.
4. Prepare and encrypt bootstrap payload: Construct a JSON payload with attacker-chosen email, username, and password fields. Convert the returned RSA public key from RSAPublicKey to SPKI format using openssl, then encrypt the payload using PKCS#1 padding: openssl pkeyutl -encrypt -pubin -inkey public_key_spki.pem -pkeyopt rsa_padding_mode:pkcs1.
5. Submit bootstrap takeover: Send POST /api/install with the base64-encoded encrypted payload as {"encrypted_params":"<base64>"}. A response of {"message":"ok"} confirms success. A follow-up GET /api/install will return {"lock":true,"timeout":false}, confirming the instance is now claimed.
6. Authenticate as administrator: Encrypt the attacker-chosen login credentials similarly and send them to POST /api/login. A successful response returns a valid session token, granting full administrative access to the nginx-ui instance (Security Advisory, GitHub Advisory).

• Network: Unexpected GET and POST requests to /api/install from external or untrusted IP addresses; POST requests to /api/crypto/public_key immediately followed by POST to /api/install from the same source; OPTIONS /api/install preflight requests from browser origins.
• Logs: nginx-ui access logs showing POST /api/install returning HTTP 200 from an IP that is not the legitimate administrator; rapid sequence of GET /api/install → POST /api/crypto/public_key → POST /api/install → POST /api/login from the same source within seconds.
• Application State: GET /api/install returning {"lock":true} before the legitimate operator completed setup; administrator account username or email not matching expected values in the nginx-ui configuration.
• File System: Unexpected or unfamiliar administrator credentials stored in /etc/nginx-ui configuration files; JWT secret or node secret values that differ from those set by the legitimate operator (Security Advisory).

As of the time of publication, no patched version of nginx-ui is available for CVE-2026-42222 (GitHub Advisory). Recommended mitigations include: (1) restricting network access to the POST /api/install endpoint via firewall rules or VPN so only trusted administrators can reach it during initial setup; (2) binding the nginx-ui setup interface to loopback (127.0.0.1) by default and using SSH tunneling for remote access during installation; (3) completing the initial setup immediately after deployment to minimize the 10-minute exposure window; (4) monitoring for unexpected requests to /api/install and /api/crypto/public_key; and (5) removing or blocking access to setup-adjacent unauthenticated endpoints such as /api/self_check and /api/restore until a patch is released. Users should monitor the nginx-ui GitHub repository for patch releases.

The vulnerability was reported by researcher Kakeru-Ishii and disclosed via the nginx-ui GitHub security advisory program. Coverage appeared across multiple vulnerability tracking platforms including VulnDB, CVEFeed, Vulners, and CIRCL's vulnerability database shortly after publication. BeyondMachines noted the issue in the context of nginx-ui patching critical RCE and admin takeover vulnerabilities. Social media activity was observed on Bluesky via CVE tracking accounts. No major vendor statements beyond the advisory itself or significant researcher commentary beyond the original reporter have been identified (GitHub Advisory).