CVE-2026-15176: NGINX ngx_http_core_module vulnerability
A vulnerability exists in NGINX Plus and NGINX Open Source when a location is configured that uses the alias directive together with rewrite and a set or return directive referencing the $requestfilename variable. Alternatively, the same result could be achieved when the $requestfilename variable is used in an access log format directive. An unauthenticated attacker along with conditions beyond their control can exploit this vulnerability by sending crafted HTTP requests. This may cause a heap buffer overflow in the NGINX worker process leading to a restart. Additionally, attackers can execute code on systems with Address Space Layout Randomization (ASLR) disabled or when the attacker can bypass ASLR.
Impact: This vulnerability may allow remote attackers to cause a denial-of-service (DoS) on the NGINX system or to possibly trigger a code execution. There is no control plane exposure; this is a data plane issue only.
Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
NGINX Plus and NGINX Open Source deployments are affected only when a location uses alias together with rewrite and a set or return directive that references $request_filename. The same condition can also arise when $request_filename is used in an access log format directive. This is a data-plane issue; there is no control-plane exposure.
Does exploitation require authentication or user interaction?
No. An unauthenticated attacker can send crafted HTTP requests, although exploitation also depends on conditions beyond the attacker’s control.
What is the likely impact of a successful attack?
The crafted requests can trigger a heap buffer overflow in an NGINX worker process, leading to a worker restart and denial of service. Code execution may be possible where ASLR is disabled or where an attacker can bypass ASLR.
How can I determine whether my configuration is at risk?
Review NGINX configuration for locations combining alias with rewrite and a set or return directive that references $request_filename. Also review access log format directives for use of $request_filename.