F5 published three advisories on October 14 for memory-corruption flaws in NGINX Plus and NGINX Open Source that unauthenticated attackers could use to crash worker processes or execute code. F5 reports no public proof-of-concept and no exploitation in the wild.
Three CVEs With Matching Severity Scores
The flaws are CVE-2026-97205, CVE-2026-93479 and CVE-2026-15176. Each is scored CVSS v3.1 8.1 (High) and CVSS v4.0 9.2 (Critical). The two scoring systems rate the same flaws differently, with the newer v4.0 score placing all three in the Critical band.
Unauthenticated attackers can crash worker processes. They can execute code on systems where address space layout randomization is disabled or bypassed. That condition explains why the v3.1 score stops at High: code execution depends on defeating a memory protection, while a crash does not.
CVE-2026-97205: Use-After-Free With Asynchronous File I/O and SSI
CVE-2026-97205, tracked by F5 as K000162608, is a use-after-free in ngx_http_core_module. It arises when asynchronous file I/O is enabled and a server-side include page uses “include virtual” commands. Both conditions must be present, so deployments that do not use SSI pages are outside this scenario.
CVE-2026-93479: Heap Buffer Overflow in map Directives
CVE-2026-93479, tracked as K000162607, is a heap buffer overflow. It occurs when a map directive uses regular expression matching and the root directive or an access log references regex capture variables before the map output variable. The trigger is a specific ordering of configuration variables, which means the flaw depends on how an administrator wrote the configuration.
CVE-2026-15176: The Third NGINX Advisory
The third flaw, CVE-2026-15176, is covered by its own F5 advisory and carries the same scores as the other two. The sources provided do not describe its mechanism.
SSI and map Directive Configurations Determine NGINX Exposure
Two of the three flaws require particular configurations: SSI with asynchronous file I/O for the use-after-free, and regex-based map directives with specific variable ordering for the heap overflow. Administrators therefore cannot assume every NGINX deployment is vulnerable, and they cannot assume any is safe without checking the configuration against the advisory conditions.
The flaws are memory-safety bugs in a server written in C. This vulnerability class has long produced remote code execution risks in network-facing software, and the dependency on ASLR in these advisories shows how modern protections shape the outcome. With ASLR active, a crash is the more likely result. Where it is disabled or bypassed, code execution becomes possible.
NGINX’s Role as Reverse Proxy, API Gateway and Ingress
NGINX is widely used as a reverse proxy, API gateway and Kubernetes ingress. A flaw in a worker process that sits in front of other services can therefore affect everything routed through it. A crash would interrupt traffic for the services behind the proxy, and code execution would place an attacker on a host that handles inbound traffic for those services.
F5’s recommendation is to upgrade to fixed NGINX releases. The advisories report no workaround in the sources provided.
No Public Proof-of-Concept for the NGINX Flaws Yet
F5 says there is no public proof-of-concept and no exploitation in the wild for any of the three flaws. That puts the advisories in the category of fixes issued before attackers take an interest. Once a vendor publishes details of a bug in a widely deployed server, researchers and attackers alike can study the fix to work out how to trigger the flaw. The sources do not report that anyone has done so.
The matching scores across all three CVEs and the single-day release suggest they were handled as a batch. F5 has not said who found the flaws or whether they came from internal review or an outside report, so the origin of the bugs remains unstated in the available material.
