NGINX is critically vulnerable: hackers can crash servers and run remote code with no authentication

A critical NGINX vulnerability, undiscovered for 18 years, allows hackers to crash servers with ease and even take full control without authentication in some common configurations. Emergency patches for the internet’s most popular web server were released on Wednesday, but working exploits are already public.

Depthfirst, an AI-native security platform, disclosed 4 memory corruption issues affecting NGINX Plus and NGINX Open Source, the most severe of which enables remote code execution.

The proof-of-concept remote code execution exploit was released on the same day the patches were made available.

Hackers can target websites just by sending malformed HTTP requests.

The bug in the NGINX rewrite module ngx_http_rewrite_module, tracked as CVE-2026-42945, is the most severe – 9.2 out of 10. It was introduced back in 2008, meaning all NGINX versions from 0.6.27 to 1.30.0 are vulnerable.

“This vulnerability may allow remote attackers to cause a denial-of-service (DoS) on the NGINX system or to possibly trigger code execution. There is no control plane exposure; this is a data plane issue only,” F5, the owner of Nginx, confirms in the released security advisory.

F5 released patched NGINX versions 1.31.0 and 1.30.1 just 14 hours ago at the time of publication.

While there are no reports about active exploitation of the bugs, they’re likely imminent.

Millions of servers in danger

All the attackers need to exploit the flaw is to send specially crafted HTTP requests that overflow the server’s memory. In most cases, it will crash the NGINX worker process, which then automatically restarts, causing denial of service.

However, in certain common configurations – on servers with rewrite directives and Address Space Layout Randomization (ASLR) disabled – attackers can go much further and execute arbitrary code.

AlmaLinux, which independently verified the exploit, acknowledged that the denial-of-service path is trivial to implement and a single crafted request reliably crashes a worker process.

“The remote code execution component is a different story. Turning the heap overflow into reliable code execution is not trivial in the default configuration, and on systems with ASLR enabled, we do not expect a generic, reliable exploit to be easy to produce,” AlmaLinux explains in the advisory.

“That said, ‘not easy’ is not ‘impossible,’ and the worker-crash DoS is exploitable enough on its own that we recommend treating this as urgent.”

Vulnerable NGINX configurations with rewrite directives and ASLR disabled are common across WordPress and PHP websites, shared hosting platforms that auto-generate NGINX configs, companies migrating APIs, and software-as-a-service platforms that route requests internally to log which resources were accessed.

Hackers can trivially scan the entire internet to quickly find vulnerable instances, checking for server responses and identifying exploitable configurations. Attackers don’t need any authentication to send malformed requests to servers.

The problem lies in how NGINX rewrites requests when routing them to the backend. In the first step, it calculates how much memory to reserve. But later, when NGINX rewrites URLs, it expands certain special characters for safe transmission. Thus, a “+” becomes “%2B”, an “&” turns into “%26,” taking more bytes and quickly running out of allocated memory.

The request can overflow it and spill into adjacent server memory, which can then be manipulated.

“If our exploit fails and crashes a worker, the master process simply spawns a new one with the exact same memory layout. This allows us to safely try multiple times until we succeed without worrying about the worker crashing and changing the memory layout,” Depthfirst said in the report.

F5 urges admins running vulnerable NGINX versions to update to the fixed versions.

“If you cannot deploy the patched nginx immediately, you can neutralize the bug by editing your nginx configuration so that no rewrite directive matches the vulnerable pattern,” AlmaLinux said.

3 more vulnerabilities

The patches also fix three other dangerous NGINX vulnerabilities:

• CVE-2026-42946: (8.3 out of 10) is an excessive memory allocation issue in two modules. Attackers can trigger a state mismatch, which causes NGINX to calculate a key length of roughly 1 terabyte, crashing the worker process.
• CVE-2026-40701: (6.3 out of 10) is a use-after-free bug in NGINX’s SSL handling. If a TLS connection closes during a DNS lookup, NGINX destroys the connection’s memory pool without canceling the resolver request. The DNS timer later attempts to access freed memory, crashing the worker process.
• CVE-2026-42934: (6.3 out of 10): An out-of-bounds read bug in NGINX's character encoding module. An off-by-one error (a counting mistake) causes NGINX to read memory just outside its intended boundary, which can corrupt its internal state.

Unlock exclusive Cybernews content on YouTube.