Nginx UI patches MCP tool that skipped config safety checks

Nginx UI, an open-source web interface for the Nginx web server maintained by the developer 0xJacky, has fixed a flaw that let an AI agent or an authenticated caller write dangerous configuration directives to disk and reload the server. The issue was published in the US National Vulnerability Database on 12 October 2026 as CVE-2026-84317, and is fixed in version 2.4.1. All releases before that are affected.

According to the advisory, Nginx UI includes a security control in internal/config/validation.go called ValidateConfigFile. It is designed to block a specific set of nginx directives that can lead to code execution: the js_* and perl_* families, load_module for the njs and perl modules, and user root. The control was applied on three of the four code paths that can write a configuration file.

The fourth path was not covered. That path is nginx_config_add, a tool exposed through MCP, the Model Context Protocol, which is the interface that lets AI agents call application functions. The advisory says the tool takes the content supplied by the caller, writes it straight to disk, and reloads nginx without ever calling the validation function. Notably, a sibling MCP path, mcp/config/config_modify.go, did call it, so the gap was specific to the add operation rather than to MCP as a whole.

The practical effect, according to the advisory, is that an authenticated MCP caller can inject exactly the directives the control exists to block. So can an MCP agent that has been induced to do so through prompt injection, where text the agent reads is crafted to make it issue attacker-chosen instructions. The result is nginx code execution on deployments where the njs or perl module is available. The advisory names the official Docker image as an example of such a deployment.

That last detail matters for working out exposure. The flaw does not grant code execution everywhere. It depends on the relevant module being present in the running nginx build. Administrators who deploy Nginx UI from the project's own container image should assume the precondition is met.

The case is a clean example of a pattern that keeps recurring in software that has added an agent-facing interface to an existing application. The security control was written and tested against the paths that existed when it was introduced. A newer surface was added alongside, and the control was not extended to it. Nothing in the validation logic itself failed. It simply was not called.

It also shows why the authentication boundary around MCP tools is weaker than it looks. The advisory describes the attacker as an authenticated MCP caller or an agent influenced by prompt injection. In the second case, the agent holds legitimate credentials and the injected instruction travels on those credentials. Any check that relies on the caller being trusted will pass.

Operators should upgrade to Nginx UI 2.4.1. The fix is in a commit published to the project's GitHub repository and is referenced from the GitHub security advisory GHSA-76pm-mq2q-9gcr. Those who cannot upgrade immediately may wish to review existing nginx configuration files written through the interface for the blocked directives, and to restrict which agents hold MCP access to the instance.