Live › vulnerability › CVE-2026-84316
Go to dashboardNginx UI, a web interface for managing Nginx, has a validation bypass where a config directive denylist only checks the first directive per line, so an authenticated user can smuggle in restricted directives like load_module, js_import, perl or user root after a semicolon. When an executable module is available, the injected config can run code in the Nginx worker context.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 19:13 UTC, 0h before NVD. All times on this page are UTC.
| Product | Ecosystem | Affected | Fixed in |
|---|---|---|---|
| github.com/0xJacky/Nginx-UI | go | < 1.9.10-0.20260703131214-23d1934099b0 | 1.9.10-0.20260703131214-23d1934099b0 |
1.9.10-0.20260703131214-23d1934099b0 (sources also say prior to 2.4.1)2.4.1 or the commit .20260703131214-23d1934099b0 or later1.9.10-0Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
Nginx UI is a web user interface for the Nginx web server. Prior to 2.4.1, config.ValidateConfigDirectives splits configuration by newline and checks only the first directive token on each line even though Nginx permits multiple semicolon-separated directives on one line. An authenticated caller can place a benign directive first and a restricted load_module, js_import, perl, or user root directive later on the same line, or can use an unrestricted include directive to load restricted content. These mechanisms bypass validation on REST, nginx_config_modify, site, and stream write paths; when an executable module is available, the injected configuration can execute code in the Nginx worker context. This issue is fixed in version 2.4.1.
This page as .md · .json · in your agent: get_signal("CVE-2026-84316")
Go Vulnerability Database, CC-BY 4.0 · EPSS scores by FIRST, used with attribution · NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.