F5 NGINX: three critical flaws, possible unauthenticated RCE

In mid-October 2026 F5 released fixes for several NGINX vulnerabilities, three of them critical: CVE-2026-15176, CVE-2026-93479 and CVE-2026-97205, all scored CVSS 9.2 (CVSS v4.0, according to CSO Online). BleepingComputer and CSO Online describe the patches as out-of-band. A remote, unauthenticated attacker can exploit them with crafted HTTP requests, but only with specific, non-default configurations. The certain outcome is a crash or restart of the worker process (denial of service); code execution is possible if ASLR is disabled or can be bypassed.

According to BleepingComputer and CSO Online, F5 has no evidence of active exploitation. The Centre for Cybersecurity Belgium (CCB) published an advisory urging immediate patching. According to Security Affairs, eleven issues were fixed in total: this figure comes from that outlet only.

Affected products

According to BleepingComputer and CSO Online: NGINX Plus, NGINX Open Source, NGINX Ingress Controller, NGINX Gateway Fabric and NGINX Instance Manager. The sources do not list vulnerable or fixed versions: check F5’s advisories for each product and, for NGINX Open Source installed from a Linux distribution’s packages, the distribution’s own advisories.

The three vulnerabilities

• CVE-2026-15176: heap buffer overflow in the worker process. It occurs in configurations that use the alias directive in a location block together with the $request_filename variable.
• CVE-2026-93479: heap buffer overflow related to the map directive. According to Security Affairs it affects configurations where regular-expression capture variables of a map are referenced before the map output variable, or where a non-cacheable variable is used in a string expression, under certain conditions.
• CVE-2026-97205: a use-after-free according to Security Affairs, with asynchronous file I/O (AIO) enabled, when NGINX processes Server Side Includes (SSI) pages containing include virtual commands. It can corrupt memory or terminate the worker.

The sources disagree on the module: Security Affairs places CVE-2026-97205 in ngx_http_core_module, CSO Online puts both it and CVE-2026-15176 there, while BleepingComputer attributes both to ngx_http_v3_module (HTTP/3). The configuration conditions and F5’s mitigations, however, are the same in all sources, and they are what tells you whether a server is exposed.

In MITRE ATT&CK terms, exploitation falls under T1190 (Exploit Public-Facing Application) and, for repeated crashes, T1499.004 (Endpoint Denial of Service: Application or System Exploitation). The sources report no indicators of compromise and no public exploits for these three flaws.

Impact for European and Italian organisations

NGINX acts as reverse proxy, load balancer and Kubernetes ingress in front of a huge number of web services, and TLS often terminates there. An analyst quoted by CSO Online points out that code execution at that point would expose passwords, session cookies, API tokens and private keys in clear text. Even without code execution, a worker that keeps restarting means unreachable services.

NGINX is often embedded in appliances, container images and ingress controllers, and many teams install it from their Linux distribution: according to the same analyst, Amazon Linux still listed the AIO fix as pending. The update published by F5 therefore does not reach every server on its own. Also according to CSO Online, these are the latest in a series: in May CVE-2026-42945 (“NGINX Rift”, in the rewrite module) came out with a public remote code execution proof of concept, and in June came CVE-2026-42530 in ngx_http_v3_module.

For NIS2 entities, especially digital service, hosting and managed service providers, this falls under vulnerability management with documented priorities and timelines; a significant disruption caused by an attack must be assessed for notification to the national CSIRT (in Italy, CSIRT Italia at ACN). In healthcare, NGINX often publishes patient portals and APIs of clinical applications: check those too.

What to do now

1. Build an inventory of where NGINX runs: servers, containers, ingress controllers and appliances. nginx -V shows the version and compiled modules.
2. Check the effective configuration with nginx -T: look for alias together with $request_filename, aio enabled together with ssi on, and map blocks with unnamed captures ($1, $2…).
3. Update to the fixed versions F5 lists for each product or, for distribution packages, as soon as the distribution makes them available. Start with Internet-facing servers that have the configurations from step 2.
4. If you cannot update right away, apply F5’s mitigations as reported by BleepingComputer and CSO Online:
   • CVE-2026-15176: avoid the alias directive in a location block or the $request_filename variable;
   • CVE-2026-97205: disable AIO or SSI;
   • CVE-2026-93479: use named captures instead of unnamed ones and limit their use to the block with the regex match.
5. Make sure ASLR is enabled: on Linux, cat /proc/sys/kernel/randomize_va_space should return 2. According to F5, as reported by CSO Online, the risk of code execution rises sharply without ASLR.
6. Watch for worker restarts: repeated lines such as “worker process … exited on signal” in the NGINX error log may point to exploitation attempts. Run workers as an unprivileged user and segment the reverse proxy network from the most critical internal systems.

How ARXDOME helps

ARX Sentry’s inventory lists software, processes and ports on every server with the agent, so you can find where NGINX runs. ARX Shield shows open vulnerabilities by machine and by package, and ARX Expose shows which of your company’s public services have known vulnerabilities: together they help you decide which servers to start with.

Last updated: 20 October 2026