Three Critical Flaws in NGINX Could Let Attackers Crash or Hijack Web Servers

Key points

• F5 disclosed three critical-rated NGINX vulnerabilities on 2026-10-14, each carrying a CVSS score (a standardised severity rating out of 10) of 9.2.
• CVE-2026-15176 and CVE-2026-93479 are heap buffer overflow bugs; CVE-2026-97205 is a use-after-free flaw. All three affect NGINX Plus and NGINX Open Source.
• All three can be triggered by an unauthenticated outsider, meaning no login is needed to attempt an attack.
• Successful exploitation can crash the web server or, on systems without a key memory-protection feature, allow full remote code execution, meaning an attacker runs their own programs on the machine.
• F5 says none of the three flaws have been exploited in the wild as of the patch date.

NGINX (pronounced "engine-x") is one of the most common pieces of software on the internet. Businesses of every size use it as a web server, the software that receives visitors' requests and sends back web pages, or as a reverse proxy, a gatekeeper that routes traffic between users and internal systems. Patching it matters well beyond tech companies.

What exactly is wrong?

All three bugs live in NGINX's worker process, the part of the software that handles incoming web requests. Each is a different path to the same destination: a heap buffer overflow, where a program writes more data than it was supposed to into a region of memory, corrupting whatever was stored next to it.

The first two activate when NGINX is configured in specific but not unusual ways involving URL-rewriting rules or variable mappings. CVE-2026-97205 requires asynchronous file input/output (a performance setting that processes multiple file reads at once) to be active alongside Server Side Includes, which lets a web page pull in content from other files on the server.

For each flaw, the attacker sends crafted HTTP requests, meaning web traffic specially constructed to trigger the defect rather than request a normal page. The minimum result is a crash that takes the worker process down and briefly interrupts service: a denial-of-service attack, where legitimate users can no longer reach the site.

How bad could code execution actually get?

Worse than a crash, and the answer turns on one defensive setting. ASLR, which stands for Address Space Layout Randomisation, is a memory-protection feature built into modern operating systems. It randomises where programs store their code in memory, making it much harder for an attacker to predict where to aim a payload. All three NGINX flaws can escalate from a crash to full remote code execution only when ASLR is disabled or when the attacker can find a way around it.

Most modern Linux servers run ASLR by default. Embedded systems and stripped-down cloud images may not. That's the population administrators should audit first.

F5 is clear on scope: there is no control-plane exposure here. The risk sits entirely in the data plane, the layer that processes ordinary web traffic.

This disclosure landed the day after we reported on a PAN-OS code injection bug already being actively exploited, a reminder that this patch cycle has been unusually heavy. Juniper Networks published advisories the same week covering more than 150 vulnerabilities across Junos OS and related products, roughly two dozen of them critical-severity. Neither company has reported active exploitation.

Should you worry?

Administrators running NGINX Plus or NGINX Open Source should apply F5's patches immediately. If an immediate update isn't possible, review your configuration for the directive combinations that trigger each flaw and remove or rewrite them as a temporary measure. Verify that ASLR is enabled on every host running NGINX.

For ordinary website visitors, there's nothing to act on. These vulnerabilities sit in server software, not in browsers or client devices. The absence of in-the-wild exploitation is the one genuinely reassuring note here: these are serious bugs and F5 got patches out before anyone appears to have weaponised them.