Skip to content
Security & Trust

F5 patches NGINX flaw that can crash workers and, in some setups, run code

CVE-2026-15176 depends on how NGINX is configured, so a version check alone will not tell you if you are exposed

W
WebPulse Newsroom
AI-assisted · 4 min read
Share on X LinkedIn
F5 patches NGINX flaw that can crash workers and, in some setups, run code
In brief
  • F5 disclosed CVE-2026-15176, an NGINX heap overflow that can restart worker processes and, if memory protections are off or bypassed, possibly allow code execution.
  • Exposure depends on configuration: the alias directive with rewrite, or the $request_filename variable in set, return or log formats.
  • Search configs for those settings, then check your own branch in F5's tables, because some branches may have no fixed version yet.

The weak spot is a setting, not a product

Most patch reports ask one question: which version are we running? The NGINX flaw F5 disclosed this week shows why that is not enough. Whether CVE-2026-15176 can hurt you depends on your version and on how your NGINX servers are configured. The lesson is that you need an inventory of configurations as well as an inventory of software.

What F5 reported

F5 says the flaw affects NGINX Plus and NGINX Open Source. Someone with no login can send specially built web requests that write past the end of a block of memory in an NGINX worker. That is a heap buffer overflow. The worker is the process that serves web traffic, and F5 says the result can be a restart of that worker.

Code execution is also possible in some cases, according to F5. It requires a host where ASLR is switched off, or one where the attacker finds a way around it. ASLR randomizes where programs sit in memory so attackers cannot predict targets. F5 adds that the attacker also needs conditions outside their control.

F5 says there is no control plane exposure. It calls this a data plane issue only. F5 says its own staff found the flaw, and it classifies it as CWE-122, a heap-based buffer overflow.

How the flaw is triggered

F5 names two setups. In the first, a location block uses the alias directive, which maps a web address to a folder on disk. It also uses rewrite, plus a set or return directive that references the $request_filename variable. That variable holds the file path NGINX works out for a request.

In the second setup, the same variable appears in an access log format. This is the part executives should notice. A logging line is not usually thought of as attack surface, yet F5 says it can produce the same result.

Consider a hypothetical. An engineer might have added such a setting years ago for convenience and forgotten it. That is an illustration only. Neither F5 nor BleepingComputer reports it.

Mitigation, and what the tables say

F5 recommends avoiding the alias directive in a location block and avoiding the $request_filename variable. It also lists fixed versions branch by branch in the tables of its advisory.

Not every branch has a fix. F5 says that if the "Fixes introduced in" column shows no version for a branch, no update candidate currently exists for it. F5 also evaluates only versions that have not reached End of Technical Support. Teams should find their own branch in the F5 tables rather than assume a patch is available.

BleepingComputer reported the disclosure as part of a wider out-of-band release, meaning patches issued outside the normal schedule. It describes three flaws as critical severity: CVE-2026-15176, CVE-2026-97205 and CVE-2026-93479. It says F5's patches span more NGINX products than the two named in the advisory: Ingress Controller, Gateway Fabric and Instance Manager. It also says exploitation needs non-default configurations.

BleepingComputer lists workarounds for the other two flaws. For CVE-2026-97205, it names disabling asynchronous file I/O or Server Side Includes. For CVE-2026-93479, it suggests named captures instead of unnamed ones.

One detail does not match. BleepingComputer places CVE-2026-15176 in the ngx_http_v3_module. The F5 advisory describes the flaw through alias, rewrite and $request_filename and does not mention that module. Teams should rely on the F5 advisory for conditions and affected versions.

F5 products and exploitation history

BleepingComputer says F5 has not yet flagged these issues as exploited in the wild. The outlet counts eight F5 vulnerabilities that CISA, the U.S. cybersecurity agency, has marked as exploited in attacks since November 2021. Four of them were also used in ransomware campaigns.

The outlet adds a second data point. F5 said in October 2025 that state-backed hackers had entered its systems in August 2025. They took source code and details of BIG-IP flaws that had not been made public. That incident involved BIG-IP, not NGINX, and neither report links it to CVE-2026-15176. It is context on how F5 products have been targeted, not evidence about this flaw.

What to ask your team

Start with five questions. Where do we run NGINX Plus, NGINX Open Source and the related Kubernetes products? Which configurations use alias together with rewrite, set or return? Which use $request_filename, including in log formats? Is ASLR enabled on those hosts? For each branch we run, does the F5 table list a fixed version, or is it past end of support?

A search through configuration files can show whether the trigger settings exist. That narrows your exposure. The version tables in F5's advisory then confirm whether a given server is affected. A weakness that hides in a setting is easy to miss in a version report. Knowing what your servers are told to do matters as much as knowing what they run.

Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: F5, Inc..

Share this insight