Nginx UI EUVD-2026-97905

Requires an authenticated Nginx UI account (a 'secondary authenticated user', consistent with PR:L) with access to the MCP configuration interface on a version prior to 2.4.1. The exploitable path is specifically the MCP config interface, which fails to reject the restricted directives load_module, js_import, and js_content that the regular HTTP configuration API correctly blocks; the attacker must be able to load ngx_http_js_module.so and trigger an Nginx reload. Limiting factors: exploitation is not possible unauthenticated, depends on the MCP interface being reachable/enabled for the account, and the Nginx build must support the NJS/js module. Upgrading to 2.4.1 removes the bypass.

This is a genuine high-priority issue for anyone running Nginx UI below 2.4.1, but it is a privilege/protection-boundary failure rather than an internet-wide mass-exploitation threat. The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:H, base 8.3) indicates a network-reachable, low-complexity attack that nonetheless requires an authenticated low-privileged account (PR:L), so it is not unauthenticated. The core weakness (CWE-693, Protection Mechanism Failure) is well-supported by the description: the hardened HTTP config API correctly rejects load_module/js_import/js_content, but the MCP configuration interface fails to enforce the same restriction, letting an authenticated user reach code execution in the Nginx worker. No EPSS score, CISA KEV listing, or public POC was provided in the input, so exploitation probability cannot be quantified and there is no public exploit identified at time of analysis. The dominant mitigating signal is the PR:L requirement - an attacker must already hold a valid (secondary) account - which limits this to insider/post-compromise or multi-tenant scenarios rather than opportunistic scanning. Note a data caveat: the official vector rates confidentiality only C:L, yet achieving arbitrary NJS execution in the worker context would typically enable broad read access, so the real confidentiality impact may be understated - verify against the vendor advisory.

An attacker holding a secondary low-privileged Nginx UI account (prior to 2.4.1) uses the MCP configuration interface - which, unlike the HTTP config API, does not reject restricted directives - to write a configuration that loads ngx_http_js_module.so and imports attacker-controlled JavaScript. After triggering an Nginx reload, the attacker-supplied NJS executes in the Nginx worker context, yielding code execution on the host. No public proof-of-concept was identified in the provided data; exploitation requires authenticated access (PR:L) but is otherwise low-complexity.