CVE-2026-84317 in nginx-ui
Summary
by MITRE • 10/13/2026
Nginx UI is a web user interface for the Nginx web server. Prior to 2.4.1, 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, and mcp/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). This issue is fixed in version 2.4.1.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/13/2026
The Nginx UI serves as a web-based management interface for configuring and managing the Nginx web server, providing administrators with a graphical means to modify server settings without direct command-line access. A critical security flaw was identified within this application prior to version 2.4.1, specifically involving an inconsistency in how configuration validation controls are applied across different API endpoints. The vulnerability centers on the ValidateConfigFile function located in internal/config/validation.go, which is designed as a primary security control to prevent the execution of dangerous Nginx directives. These restricted directives include those prefixed with js_ and perl_, which allow for server-side scripting via njs or Perl modules, load_module instructions that can dynamically load arbitrary shared libraries into the Nginx process, and user root configurations that could alter privilege levels within the containerized environment.
The technical flaw arises from an incomplete implementation of this security control across all configuration modification paths. While three out of four endpoints responsible for writing configuration changes—specifically api/config/add.go, api/config/modify.go, and mcp/config/config_modify.go—correctly invoke the ValidateConfigFile function to sanitize input before saving it to disk, a fourth endpoint remains unprotected. The MCP tool nginx_config_add, implemented in mcp/config/config_add.go, bypasses this validation step entirely. Instead of parsing and validating the incoming configuration data against the whitelist of allowed directives, this specific path writes the caller-supplied content directly to the Nginx configuration file on disk and subsequently triggers a reload of the server process. This architectural inconsistency creates a direct vector for exploitation where an attacker can circumvent the intended security boundaries by targeting the unvalidated endpoint.
The operational impact of this vulnerability is severe, particularly in environments running official Docker images or other deployments where njs or Perl modules are enabled. Because Nginx executes these scripting languages within its worker processes, injecting a malicious js_ directive allows an authenticated MCP caller to execute arbitrary code with the same privileges as the Nginx process. In many containerized setups, this may equate to root-level access depending on how the container is configured. Furthermore, if an attacker can induce prompt injection against an MCP agent that utilizes this endpoint, they could potentially compromise the system without direct authentication credentials, expanding the attack surface significantly. The ability to load arbitrary modules via load_module directives further exacerbates the risk by allowing the execution of compiled code within the server process context.
This vulnerability is classified under CWE-94 as Improper Control of Generation of Code or Script, specifically reflecting a failure in input validation that leads to remote code execution. From an ATT&CK perspective, it aligns with techniques involving Command and Scripting Interpreter abuse, where adversaries leverage legitimate system tools for malicious purposes. The root cause is identified as CWE-913, Improper Control of Dynamically-Managed Code Resources, due to the inconsistent application of security controls across different code paths within the same application logic. To mitigate this risk, organizations must immediately upgrade Nginx UI to version 2.4.1 or later, which rectifies the oversight by ensuring that all configuration write operations pass through the ValidateConfigFile function. Additionally, administrators should verify that their deployments do not enable unnecessary modules such as njs or Perl if they are not actively required for business functions, thereby reducing the potential impact of any future vulnerabilities in these components.