NGINX Rift (CVE-2026-42945): What It Is and How to Fix It

What happened?

On May 13, 2026, a critical vulnerability was publicly disclosed in NGINX — the web server that powers roughly 34% of all websites on the internet. The vulnerability is tracked as CVE-2026-42945 and has been nicknamed NGINX Rift. It carries a CVSS v4 score of 9.2 out of 10 (Critical).

The bug is a heap buffer overflow in NGINX's ngx_http_rewrite_module — the part of NGINX that handles URL rewrites. It has been sitting in the codebase since 2008, affecting every NGINX version from 0.6.27 through 1.30.0. That's 18 years undetected.

An unauthenticated attacker can exploit it by sending a single crafted HTTP request. No login, no session, no special access needed. On systems with ASLR disabled, this can lead to full remote code execution. On modern systems with ASLR enabled, it causes worker process crashes — effectively a denial-of-service attack.

How the bug works (simple version)

When NGINX rewrites a URL, it works in two steps. First, it measures how much memory it needs for the new URL. Then, it writes the new URL into that allocated memory.

The problem occurs when your rewrite rule contains a ? (question mark) in the replacement string. This sets an internal flag called is_args on the main engine. But the first step — the measurement step — runs on a fresh sub-engine that doesn't see that flag.

So Step 1 says: "I need 50 bytes." But Step 2 applies extra URI escaping (characters like +, %, and & get expanded into longer sequences), and actually writes 80 bytes. Those extra bytes spill past the allocated buffer into adjacent memory. Since the bytes come from the attacker's URL, the attacker controls what gets written.

Am I affected?

You are affected if all three of these are true:

1. You are running NGINX Open Source 0.6.27 through 1.30.0, or NGINX Plus R32 through R36.
2. Your NGINX config uses a rewrite directive with an unnamed PCRE capture ($1, $2, etc.) and a replacement string containing a question mark (?).
3. That rewrite is followed by another rewrite, if, or set directive.

This is an extremely common configuration pattern. If you use NGINX and have non-trivial rewrite rules, you should assume you're affected until you verify otherwise.

Quick check: are you running a vulnerable version?

nginx -v

If the output shows any version from 0.6.27 to 1.30.0, you need to act.

Quick check: does your config have the vulnerable pattern?

# Search for rewrite rules with unnamed captures and question marks
grep -rn 'rewrite.*\$[0-9].*?' /etc/nginx/

If this returns results, check whether those rewrite directives are followed by another rewrite, if, or set directive. If yes, your config matches the trigger condition.

How to fix it

There are two paths: upgrade NGINX (recommended) or apply a config workaround (temporary).

Option 1: Upgrade NGINX (recommended)

The patched versions are:

• NGINX Open Source: 1.31.0 or 1.30.1
• NGINX Plus: R33 P1 or R36 P1

Ubuntu / Debian

# Update package lists
sudo apt update

# Upgrade NGINX
sudo apt install --only-upgrade nginx

# Verify the new version
nginx -v

# Restart NGINX
sudo systemctl restart nginx

# Verify NGINX is running
sudo systemctl status nginx

CentOS / RHEL / AlmaLinux / Rocky Linux

# Update NGINX
sudo yum update nginx
# or on newer systems
sudo dnf update nginx

# Verify the new version
nginx -v

# Restart NGINX
sudo systemctl restart nginx

# Verify NGINX is running
sudo systemctl status nginx

If you use the official NGINX repo

If you installed NGINX from the official nginx.org repository rather than your distro's default repo, make sure that repo is configured and then run the same upgrade commands above. You can check:

# Check if official NGINX repo is configured
cat /etc/apt/sources.list.d/nginx.list   # Debian/Ubuntu
cat /etc/yum.repos.d/nginx.repo          # CentOS/RHEL

If you compiled NGINX from source

# Download the patched source
wget https://nginx.org/download/nginx-1.31.0.tar.gz
tar -xzf nginx-1.31.0.tar.gz
cd nginx-1.31.0

# Use your existing build configuration
# You can find it with:
nginx -V

# Copy that configure line and run it, then:
make
sudo make install

# Restart
sudo systemctl restart nginx

Docker

# Update your image tag to the patched version
# In your Dockerfile or docker-compose.yml:
# FROM nginx:1.31.0

# Pull and restart
docker pull nginx:1.31.0
docker-compose up -d

Kubernetes (NGINX Ingress Controller)

If you use the NGINX Ingress Controller, update to the latest patched version. Check the F5 security advisory for the specific version numbers for NGINX Ingress Controller, NGINX Gateway Fabric, and other F5/NGINX products.

Option 2: Config workaround (temporary)

If you cannot upgrade immediately, you can mitigate the vulnerability by replacing unnamed captures with named captures in your rewrite rules.

Before (vulnerable):

rewrite ^/old-page/(.*)$ /new?$1 break;
set $var $1;

After (safe):

rewrite ^/old-page/(?P<captured>.*)$ /new?$captured break;
set $var $captured;

The key change: (.*) becomes (?P<captured>.*) and $1 becomes $captured. Named captures bypass the code path where the two-pass mismatch occurs.

Do this for every rewrite directive in your config that uses unnamed captures ($1, $2, etc.) with a ? in the replacement string.

After editing:

# Test your config for syntax errors
sudo nginx -t

# If the test passes, reload
sudo nginx -s reload

Important: This is a temporary workaround. You should still upgrade to the patched version as soon as possible.

Post-fix verification

After upgrading or applying the workaround, verify everything is in order:

# 1. Confirm the version is patched
nginx -v
# Should show 1.31.0 or 1.30.1

# 2. Test config syntax
sudo nginx -t

# 3. Check NGINX is running properly
sudo systemctl status nginx

# 4. Check your error logs for any issues
sudo tail -f /var/log/nginx/error.log

# 5. Verify your sites are responding
curl -I https://your-domain.com

What else was found?

The team at depthfirst didn't just find this one bug. Their AI-powered analysis system flagged four memory corruption issues in total:

• CVE-2026-42946 (CVSS 8.3): Excessive memory allocation in SCGI/uwsgi modules
• CVE-2026-40701 (CVSS 6.3): Use-after-free in the SSL module
• CVE-2026-42934 (CVSS 6.3): Out-of-bounds read in the charset module

All four are fixed in the same patched versions (1.31.0 / 1.30.1), so upgrading covers all of them.

Timeline

• 2008: Bug introduced in NGINX 0.6.27
• 2026 (early): depthfirst's AI system scans NGINX source code, flags the vulnerability within 6 hours
• May 13, 2026: F5 and depthfirst jointly disclose the vulnerability, patched versions released
• May 13, 2026: Proof-of-concept published on GitHub

Key takeaway

This bug sat in one of the most widely deployed open-source projects for 18 years. Thousands of developers and security researchers looked at this code and missed it. An AI system found it in 6 hours. If you run NGINX — check your version, check your config, and patch now. A proof-of-concept is already public, and automated scanners are already looking for vulnerable servers.

Stay safe. Keep your infrastructure updated.