CVE-2026-15176: NGINX heap overflow when alias is combined with $request_filename

What it is

NGINX can overflow a heap buffer in a worker process when it handles a crafted HTTP request for a certain kind of location. An unauthenticated attacker over the network can trigger it. The result is a worker crash and restart. If ASLR is disabled on the host, or the attacker can bypass it, code execution is possible.

The bug is in ngx_http_core_module, so it sits in the data plane only. F5 says the control plane is not exposed. F5 rates it CVSS 8.1 (v3.1) and 9.2 (v4.0), with high attack complexity because the attacker needs the right configuration to be present.

F5 found the bug itself. CISA’s SSVC data in the CVE record lists exploitation as “none” and the issue as not automatable. No public proof of concept is confirmed by a source we opened.

Am I affected?

You are exposed only if both are true:

1. You run an affected version (see the table above).
2. Your configuration includes one of these:
   • a location that uses alias together with rewrite, plus a set or return directive that references $request_filename, or
   • $request_filename inside an access log log_format directive.

Versions past End of Technical Support were not evaluated by F5, so treat them as unknown and upgrade.

To find the risky configuration, search your dumped config for the pattern:

nginx -T 2>/dev/null | grep -nE 'alias|request_filename'

Check the version with nginx -v. Include config files pulled in with include, which nginx -T prints in full.

What to do

1. Upgrade. Move NGINX Open Source to 1.31.7 or 1.30.6, and NGINX Plus to 37.1.0.1 or 37.0.5.1. If you run Plus R33 to R36, the CVE record lists no fixed version for those branches, so plan a move to a fixed release. Distribution packages may use their own version numbers; check your vendor’s changelog.

2. If you can’t upgrade tonight, remove the trigger. F5 gives two workarounds:

   • Avoid alias in a location.
   • Avoid the $request_filename variable, including in log_format.

   Production impact: replacing alias with root changes how paths map to files, so test it first. Dropping $request_filename from a log format removes that field from your logs.

3. Check ASLR on hosts that run NGINX. It turns a crash into a harder code-execution problem.

4. If the server was exposed while vulnerable, review the worker crash history below. A confirmed compromise means rebuilding the host and rotating any secrets that NGINX’s user could read, such as TLS private keys and upstream credentials.

Detection

No exploitation reports or indicators have been published. Until they are, look for the side effects of the bug:

• Repeated worker process ... exited on signal 11 (or other signals) lines in the NGINX error log, especially after unusual requests.
• Requests to locations that use alias with long or odd paths, in the access log, just before a worker restart.
• Unexpected child processes or outbound connections from the NGINX worker user.