NGINX Rift (CVE-2026-42945): An 18-Year-Old Vulnerability That Lets Anyone Take Over Your Web Server

Overview

On May 13, 2026, F5 and cybersecurity research firm depthfirst disclosed a critical vulnerability in NGINX, one of the most widely used web server software in the world. The vulnerability is tracked as CVE-2026-42945 and has been given the name NGINX Rift.

The flaw carries a CVSS v4 score of 9.2 out of 10, placing it in the critical severity category. It allows an unauthenticated attacker to either crash an NGINX worker process or, under the right conditions, execute arbitrary code on the target server all from a single crafted HTTP request.

What makes this disclosure unusual is that the bug has been sitting in the NGINX codebase since 2008, roughly 18 years without being detected by human reviewers. It was ultimately found by an autonomous AI-powered analysis system, not a human researcher.

What Is CVE-2026-42945?

CVE-2026-42945 is a heap-based buffer overflow vulnerability located in the ngx_http_rewrite_module component of NGINX. This module handles URL rewriting, one of the most commonly used features in NGINX configurations.

The vulnerability exists in every version of NGINX Open Source from 0.6.27 through 1.30.0. It also affects NGINX Plus R32 through R36.

Given how widely NGINX is deployed across the internet. Powering everything from small business websites to large enterprise APIs — the potential attack surface is enormous.

How the Vulnerability Works

To understand the bug, you need to understand how NGINX handles rewrite rules.

When NGINX processes a rewrite directive, it uses a two-pass approach:

1. The first pass calculates the size of the buffer needed to hold the rewritten URL.
2. The second pass actually writes the rewritten URL into that buffer.

The problem lies in a flag called is_args. This flag is used to signal that the rewrite replacement string contains a question mark character, which changes how certain characters are encoded during output.

During the first pass, the one that calculates the buffer size, NGINX creates a fresh sub-engine with zeroed state. This sub-engine does not have the is_args flag set. As a result, it calculates a smaller buffer size than what will actually be needed.

During the second pass , the actual write , the main engine has is_args set correctly. Characters such as +, %, and & expand during re-escaping. The write operation then overflows past the end of the allocated buffer.

The result is a classic heap buffer overflow. An attacker can trigger this condition by sending a single crafted HTTP request to a vulnerable NGINX server that uses certain rewrite configurations.

Specifically, the vulnerable pattern involves a rewrite directive that uses unnamed PCRE captures (such as $1 or $2) with a replacement string containing a question mark, followed by another rewrite, if, or set directive.

What Can an Attacker Do?

The impact depends on the target environment.

Denial of Service: In all affected configurations, an attacker can crash the NGINX worker process. This causes service disruption and may require manual intervention to recover.

Remote Code Execution: On servers where ASLR (Address Space Layout Randomization) is disabled, the vulnerability can be exploited to achieve remote code execution. A public proof-of-concept exploit is already available on GitHub.

Lateral Movement on Shared Infrastructure: This is where the risk becomes especially serious for hosting providers and managed service environments. When an attacker achieves code execution in the NGINX worker process, they gain access to the user account under which NGINX runs, typically www-data or a similar unprivileged system account.

On a properly isolated server, this limits the damage. But on shared hosting environments without per-user process isolation, this access can translate to:

• Read and write access to every customer web root on the server
• Database credentials stored in configuration files such as .env and wp-config.php
• The ability to write malicious payloads and execute further attacks

The exploit code has been publicly released, which means the window for unpatched systems to be targeted is closing fast.

How Was It Discovered?

The story behind the discovery is as notable as the vulnerability itself.

CVE-2026-42945 was found by depthfirst, a security research company that built an autonomous vulnerability analysis system. The system was pointed at the NGINX source code as a test. Within six hours, it flagged the heap overflow, along with three other memory corruption issues that had also gone undetected for years.

Those three additional vulnerabilities are:

• CVE-2026-42946 (CVSS 8.3): Excessive memory allocation in the ngx_http_scgi_module and ngx_http_uwsgi_module modules. An unauthenticated remote attacker in a man-in-the-middle position could read NGINX worker process memory or force a restart.
• CVE-2026-40701 (CVSS 6.3): A use-after-free flaw in the ngx_http_ssl_module, allowing limited data modification or process restart when client certificate verification and OCSP are both enabled.
• CVE-2026-42934 (CVSS 6.3): An out-of-bounds read in ngx_http_charset_module, which could lead to memory disclosure or an NGINX process restart.

The original vulnerability was responsibly disclosed to F5 on April 18, 2026. F5 coordinated the fix, and patches were released alongside the disclosure on May 13, 2026.

Affected Versions

NGINX Open Source:

• All versions from 0.6.27 through 1.30.0 are vulnerable.
• Version 1.31.0 and 1.30.1 contain the fix.

NGINX Plus:

• R32 through R36 are vulnerable.
• The F5 advisory contains the corresponding patched release.

If you are running any version below 1.31.0 (or below 1.30.1 on the stable branch), assume you are affected unless your configuration is confirmed to not use the vulnerable rewrite pattern.

How to Fix It

Option 1: Patch Immediately

Upgrade to NGINX 1.31.0 or 1.30.1. These versions are available from the official NGINX repository at nginx.org.

For NGINX Plus users, apply the patch described in the F5 security advisory directly.

After patching, verify the version:

nginx -v

The output should confirm version 1.31.0 (or 1.30.1 on the stable channel).

Option 2: Apply the Configuration Workaround

If patching is not immediately possible, F5 recommends a configuration-level mitigation. The fix is to replace unnamed PCRE captures : $1, $2, and so on with named captures inside the affected rewrite directives.

This removes the triggering condition for the buffer size miscalculation that leads to the overflow.

This workaround reduces risk but should not be treated as a permanent solution. Upgrade as soon as possible.

Option 3: Harden the Runtime Environment

In addition to patching, ensure that:

• AppArmor or SELinux profiles are enforced on the NGINX worker process. When properly configured, these controls prevent an attacker from executing arbitrary binaries or writing outside designated directories, even after a successful exploit.
• NGINX is running as an unprivileged user.
• ASLR is enabled on the operating system level.
• Unused NGINX modules are disabled to minimize attack surface.

What This Means for the GCC and MENA Region

NGINX is widely deployed across government portals, financial institutions, e-commerce platforms, and enterprise web infrastructure throughout the GCC. Many organizations in this region rely on NGINX as a reverse proxy in front of business-critical applications.

Given that the proof-of-concept exploit is already public and the vulnerability requires no authentication, threat actors will attempt to scan and exploit unpatched internet-facing systems quickly. This is not a theoretical risk, it is an active one.

Organizations in the MENA region should treat this as a priority patch, not a scheduled maintenance item.

Specifically:

• Run an immediate inventory of NGINX instances across your environment, including those behind load balancers and in containerized workloads.
• Check whether any of those instances use rewrite rules with unnamed captures and question mark replacements.
• Prioritize patching any instance exposed to the public internet.
• Monitor for anomalous HTTP requests targeting rewrite rule patterns.

The Bigger Picture: AI-Driven Vulnerability Discovery

The way CVE-2026-42945 was found carries a message beyond the vulnerability itself.

NGINX is one of the most audited open source projects in existence. Thousands of engineers, security researchers, and contributors have reviewed its code over 18 years. Despite that, a critical heap overflow sat undetected in a core module from 2008 until 2026.

An autonomous AI system found it in six hours.

This is not a criticism of the NGINX project or its maintainers. It is a signal that the tools for finding bugs have crossed a capability threshold. AI-powered code analysis can now systematically examine memory handling patterns across large codebases at a scale and consistency that human review cannot match.

The implication is straightforward: the vulnerabilities that remain undiscovered in software you depend on today are not necessarily safe just because they have not been found yet. They may simply be waiting for a sufficiently capable tool to be pointed at the code.

For security teams, this means the attack surface is less predictable than it used to be. Defense in depth, isolation, least privilege, monitored runtime behavior, and rapid patch capability, matters more, not less.

Summary

CVE-2026-42945 is a critical heap buffer overflow in NGINX’s rewrite module. It has been present in the codebase for 18 years, requires no authentication to trigger, and can lead to remote code execution or denial of service. A public proof-of-concept is available.

The fixed versions are NGINX 1.31.0 and 1.30.1.

If you run NGINX, patch now. If you cannot patch immediately, apply the named-capture configuration workaround and ensure runtime hardening controls are in place.

References

Additional Coverage

Dexpose provides threat intelligence and digital risk protection for organizations across the MENA and GCC region. For questions about your organization’s exposure to CVE-2026-42945 or related vulnerabilities, contact the Dexpose team.