High priorityDisclosed

Advisory · CVE-2026-15176

Heap overflow in NGINX alias and rewrite handling can crash workers or run code

A vulnerability exists in NGINX Plus and NGINX Open Source when a location uses the alias directive together with rewrite and a set or return directive referencing the request_filename variable, or when that variable is used in an access log format: crafted HTTP requests can cause a heap buffer overflow in the worker process, restarting it, and can execute code where ASLR is disabled or bypassed. F5 rates it CVSS 3.1 8.1 (CVSS 4.0 9.2).

Advisory published October 14, 2026Independent summary
Vendor
F5
Product
NGINX Plus and NGINX Open Source
Identifier / CWE
CVE-2026-15176
CWE-122
Action timing
Immediate
ELI5

Explain it like I’m five

A common config pattern for serving files from another directory turns a crafted URL into a worker memory overflow.

SIMPLIFIED_ATTACK_PATH03 STEPS
  1. 01Crafted request arrives

    An attacker sends HTTP requests shaped to reach the affected NGINX configuration path.

  2. 02Worker memory corrupted or check bypassed

    The flaw takes effect in the NGINX worker or ingress data plane.

  3. 03Impact lands

    The attacker gains the access, crash, or code execution the flaw allows.

What happened

F5 disclosed CVE-2026-15176 for NGINX Plus and NGINX Open Source in module ngx_http_core_module. The trigger configuration combines alias with rewrite and a set or return directive referencing request_filename, or uses request_filename in an access log format. An unauthenticated attacker with conditions beyond their control can send crafted HTTP requests to overflow the worker heap, causing a restart, and possibly code execution on systems with ASLR disabled or bypassed. F5 lists NGINX Open Source 1.31.0 before 1.31.7 and the 1.30 line before 1.30.6, plus NGINX Plus 37.x and R33 through R36 lines, as affected.

F5’s K000162416 lists the affected versions and the fixed builds. Match your deployment to the article before changing anything.

What to do

  1. Inventory every NGINX Plus and NGINX Open Source deployment, including test, training, and individually managed instances.
  2. Apply the vendor fix or upgrade exactly as directed in the linked vendor bulletin or advisory.
  3. Restrict network access to NGINX Plus and NGINX Open Source while remediation is underway, especially for internet-facing instances.
  4. Review application and server logs for NGINX worker restarts and crash signatures on sites using alias with rewrite, and requests with unusual path lengths.
  5. Check for accounts, content, or configuration created outside normal change processes, and rotate exposed credentials where access cannot be ruled out.
  6. Verify the deployed version or patch level after remediation.

Management note

NGINX is everywhere, and alias-plus-rewrite is a cookbook configuration. Patch broadly, then grep configs for the pattern to know your real exposure.