Four CVEs show Nginx UI's MCP tool wrote nginx config without the validation and OTP step-up its REST API applies. Fixed in 2.4.1; upgrade to the current release.
Nginx UI, the open-source web admin panel for nginx, shipped an MCP (Model Context Protocol) interface that let authenticated callers, including AI agents, write nginx configuration without the validation the REST API applies. Four CVEs published on 17 July 2026 (CVE-2026-84317, CVE-2026-84318, CVE-2026-84319 and CVE-2026-84360, CVSS 8.1 to 8.8) describe the gap. Release 2.4.1, dated 3 July 2026, closes it. The flaw is in the agent interface, not in nginx itself.
What happened
Nginx UI keeps a denylist of dangerous directives. ValidateConfigFile rejects perl, perl_set, js_import, js_content, load_module of restricted modules, user root and others. The REST endpoint POST /api/configs calls it and refuses such content.
The MCP tool nginx_config_add did not. It wrote the caller's content to disk and reloaded nginx. The advisory for CVE-2026-84318 puts it plainly: the tool writes and reloads "without calling config.ValidateConfigFile". The sibling tool nginx_config_modify did call it, so only the add path was open.
The MCP endpoints, GET /mcp (SSE) and POST /mcp_message (JSON-RPC), accept the same JWT and node-secret tokens as the REST API. Any authenticated session therefore reached the unvalidated path.
CVE-2026-84317 and CVE-2026-84318 are one missing check, reported twice.
The four CVEs
| CVE | CVSS | Weakness | Affected | Issue |
|---|---|---|---|---|
| CVE-2026-84317 | 8.8 | CWE-20 | up to 2.3.11 | nginx_config_add skips directive validation |
| CVE-2026-84318 | 8.8 | CWE-693 | 2.0.0-rc.6 onward | Same gap, reported separately (credit: thekogo) |
| CVE-2026-84319 | 8.3 | CWE-693 | 2.x | Secondary user writes restricted directives via MCP, runs NJS in the worker |
| CVE-2026-84360 | 8.1 | CWE-288 | up to 2.4.0 | MCP routes skip the OTP secure-session step-up |
CVE-2026-84317 and CVE-2026-84318 describe the same missing call. Treat them as one defect with two records.
Why it happened
The CVE-2026-84317 advisory traces it to a hardening commit, "Harden config write paths", from 21 April 2026. It added validation to api/config/add.go, api/config/modify.go and mcp/config/config_modify.go. It did not touch mcp/config/config_add.go, which per the advisory had never called the validator. The control was added to three of four write paths, and the fourth was the one an agent could reach.
CVE-2026-84360 is the same pattern for authentication. The HTTP configuration routes sit behind RequireSecureSession, the OTP step-up for sensitive changes. The MCP routes had only AuthRequired. A user with OTP enabled but only an ordinary JWT could change config through MCP without the step-up.
Impact
The researcher's proof of concept on the official uozi/nginx-ui:2.3.11 image wrote a config with load_module for the njs module and user root, plus a script. After the reload, nginx workers ran with UID 0 and an njs handler answered requests. The same content sent through nginx_config_modify was rejected with "file content contains restricted nginx directive".
Limits matter. Exploitation needs a valid Nginx UI login, MCP enabled, and, for code execution, a Perl or njs module present on the nginx host, as in the official Docker image. The CVE-2026-84319 advisory says the result is NJS execution in the worker, "not OS command execution by itself". The CVE-2026-84317 advisory also names prompt injection of an MCP agent as a route to the same calls.
What changed in 2.4.1
We compared the source at the two tags. In v2.4.0, config_add.go goes straight to os.WriteFile. In v2.4.1 it calls config.ValidateConfigFile first, and mcp/router.go adds a requireSecureSessionForSensitiveMCPTools() handler to /mcp and /mcp_message. The change is in commit 23d1934099b0, "fix: harden security advisory paths". The release notes say only "Fixed known issues", and GitHub's advisories list no patched version, so the fix is easy to miss.
What defenders should do
- Upgrade Nginx UI to 2.4.1 or later. Later releases exist, and the project has published further advisories since, so move to the current release rather than stopping at 2.4.1.
- If you cannot upgrade, disable MCP or block
/mcpand/mcp_messageat the proxy, and restrict them to trusted addresses. - Audit
nginx.confand included files forload_module,js_import,perl_setanduser rootthat you did not put there, and check file times against reload events. - Remove unneeded njs and Perl modules from nginx hosts, and do not run workers as root.
- Treat every second write path as a security boundary. If you expose a management tool to agents, check that it goes through the same validation, authorization and step-up as the UI.
Related: our earlier coverage of NGINX Rift, CVE-2026-42945 in the rewrite module, a flaw in nginx itself.