How to Check CVE-2026-42945: Nginx Rift Trigger Conditions, Version Checks, and Upgrade Advice

CVE-2026-42945 is a security vulnerability in NGINX Open Source and NGINX Plus. It is also being referred to as Nginx Rift. The issue is in ngx_http_rewrite_module, and the vulnerability type is heap-based buffer overflow.

News like this is easy to turn into headlines such as “hidden for 18 years”, “remote control without a password”, or “30% of servers affected”. Those claims travel well, but when reading the patch notes and NVD description, it is better to separate the risk into concrete pieces: the issue is serious, and it does not require a logged-in account; but not every Nginx instance is automatically compromised. Triggering it requires specific rewrite configuration and request conditions.

Start with the official description

The NVD description of CVE-2026-42945 can be summarized as follows:

It affects NGINX Plus and NGINX Open Source.
The vulnerability is in ngx_http_rewrite_module.
The issue may be triggered when a rewrite directive is followed by a rewrite, if, or set directive, unnamed PCRE capture groups such as $1 and $2 are used, and the replacement string contains a question mark ?.
An unauthenticated attacker can send a crafted request to trigger the vulnerability.
The result may be a heap buffer overflow and restart of an NGINX worker process.
If ASLR is disabled on the system, code execution is possible.

F5, as the CNA, gives the following scores:

CVSS v4.0: 9.2, Critical.
CVSS v3.1: 8.1, High.
CWE: CWE-122 Heap-based Buffer Overflow.

So this is not a routine “bad config causes a 404” issue. It is a memory safety vulnerability covered by an official Nginx security fix.

Which claims need context

First, “no password required” is best understood as unauthenticated attack. In other words, the attacker does not need to log in to an Nginx admin panel, obtain SSH access, or hold an application account. But that does not mean every public-facing Nginx instance can be casually taken over.

Second, “direct remote control” depends on conditions. The more careful official framing is that the vulnerability can cause worker process restarts; on systems where ASLR is disabled, code execution is a possible outcome. On environments with ASLR enabled, proper distribution hardening, and restricted runtime privileges, the exploitation path becomes more complex.

Third, “30% of servers affected” should not be treated as “all Nginx market share equals exposed attack surface”. Real exposure depends on the version, whether the affected module is present, whether the specific rewrite configuration exists, whether the distribution has already backported the patch, and how hardened the Nginx runtime environment is.

The more accurate approach is simple: if you run Nginx in production, check it quickly; but do not decide whether you are affected based only on a headline percentage.

How to determine the affected scope

According to nginx.org release information, the nginx-1.30.1 stable release and nginx-1.31.0 mainline release published on May 13, 2026 include multiple security fixes, including the ngx_http_rewrite_module buffer overflow tracked as CVE-2026-42945.

If you use official Nginx source builds or official packages, focus on:

NGINX Open Source stable: upgrade to 1.30.1 or later.
NGINX Open Source mainline: upgrade to 1.31.0 or later.
NGINX Plus: check the fixed version for your F5-supported branch.

If you use Debian, Ubuntu, RHEL, AlmaLinux, Rocky Linux, Alpine, container images, Plesk, control panels, Ingress Controller, or cloud-provider managed components, do not rely only on the upstream version shown by nginx -v. Many distributions backport security fixes into older package versions. The version string may look old while the patch is already included.

One-minute urgency check

Use these questions for a quick risk tiering:

Is this Nginx instance directly exposed to the internet, or is it part of an API Gateway, reverse proxy, load balancer, or Ingress entry layer?
Are you using official Nginx packages, source builds, third-party control panels, or container images without having confirmed the CVE-2026-42945 fix status?
Does the configuration contain complex rewrite rules, especially consecutive rewrite, if, or set directives and unnamed captures such as $1 and $2?
Does any rewrite target include request paths, query parameters, or other user-controlled input?
Is the system weakly hardened, for example with ASLR disabled, overly privileged workers, or overly broad container permissions?

If the first two items apply and rewrite configuration has not yet been reviewed, treat it as high priority. Public entry points, shared environments, Kubernetes Ingress, edge proxies, and Nginx instances carrying login or API traffic should be upgraded or replaced with a confirmed fixed package first.

How to confirm fixes on Debian / Ubuntu / RHEL / Alpine

Distribution users should not look only at nginx -v. Debian, Ubuntu, RHEL, AlmaLinux, Rocky Linux, and Alpine often backport security patches into stable branches, so the visible version may still be lower than nginx.org’s 1.30.1 or 1.31.0.

On Debian / Ubuntu, check security advisories, package changelog, and upgrade candidates:

1
2
3
4


nginx -v
nginx -V
apt list --upgradable | grep nginx
apt changelog nginx | grep -i "CVE-2026-42945"

On RHEL / AlmaLinux / Rocky Linux, check security updates and package changelog:

1
2


yum updateinfo list security | grep -i nginx
rpm -q --changelog nginx | grep -i "CVE-2026-42945"

On Alpine, check the installed package version and security branch updates:

1
2


apk info -v nginx
apk version -v nginx

If the package manager, distribution security advisory, or vendor advisory explicitly says CVE-2026-42945 is fixed, you can treat it as backported even if the upstream version number looks old. Conversely, if the version looks new but the source is unclear, still confirm the build date and patch source.

How to check container images and Ingress Controller

In container environments, check the Nginx inside the image, not only the host. First confirm the actual embedded version:

1
2


docker run --rm your-nginx-image nginx -v
docker run --rm your-nginx-image nginx -V

Also check whether the base image has been updated. If the image is built on Debian, Ubuntu, Alpine, or distribution packages, apply the same advisory and changelog checks for that distribution. Restarting an old image is not useful; the image itself needs to be rebuilt or replaced.

For Kubernetes Ingress, confirm three things:

Whether the Ingress Controller project has published an advisory or fixed release for CVE-2026-42945.
Whether the running controller image digest has actually changed, rather than only the tag.
Whether the controller’s embedded Nginx version, build flags, and template configuration still contain high-risk rewrite rules.

Start by checking the running image:

1
2


kubectl -n ingress-nginx get pods -o wide
kubectl -n ingress-nginx describe pod <pod-name> | grep -i image

If you use a cloud-provider managed Ingress or gateway, check the corresponding cloud service advisory. Managed components usually cannot be fixed by running apt upgrade yourself; you need the provider’s fix or a switch to a fixed version.

Which rewrite patterns deserve attention

This vulnerability is related to rewrite configuration. Start by searching Nginx configuration:

1
2


grep -R "rewrite" /etc/nginx -n
grep -R "\\$[0-9]" /etc/nginx -n

Pay attention to patterns like:

1

rewrite ^/old/(.*)$ /new/$1? permanent;

The unnamed captures such as $1 and $2, plus the ? in the replacement target, are among the key conditions described by the official sources. During review, pay special attention to:

A rewrite followed by another rewrite, if, or set.
Broad captures such as (.*) and (.+) that are reused as $1 or $2.
Rewrite targets containing ? to append or discard query parameters.
Rewrite input coming from public paths, Host, URI, parameters, or upstream-controlled values.
Rewrite rules generated by panels, gateways, Ingress annotations, or templates.

If you cannot upgrade immediately, use temporary mitigations:

Reduce complex rewrite rules.
Replace unnamed captures with clearer named captures.
Avoid unnecessary ? concatenation in replacement strings.
Add WAF or reverse-proxy rules for high-risk entry points.
Confirm that ASLR is enabled.
Reduce Nginx worker privileges and verify systemd sandboxing, SELinux/AppArmor, and related hardening.

These measures are mitigations, not replacements for patching.

Remediation priority

Prioritize by exposure:

Public-facing Nginx entry points.
Reverse proxies, API Gateway, and edge gateways.
Nginx in multi-tenant environments.
Kubernetes Ingress Controller.
Plesk, control panels, marketplace images, and other components that bundle Nginx.
Internal Nginx instances that carry critical business traffic.

How to verify after upgrading: nginx -t, reload, and worker state

After updating, do not stop at “the package manager succeeded”. Confirm the configuration, process state, and actual binary have all switched over. First validate the configuration:

1

nginx -t

If there are no errors, reload smoothly:

1

systemctl reload nginx

If the package upgrade replaced the binary, confirm old workers have exited:

1

ps aux | grep nginx

You can also inspect the master process start time and binary path to ensure the running service is not an old process still resident in memory. If needed, schedule a maintenance window and restart the service so old workers or old containers do not continue handling requests.

For containers and Ingress, also confirm the new image rollout has actually completed:

1
2


kubectl -n ingress-nginx rollout status deployment/<deployment-name>
kubectl -n ingress-nginx get pods -o wide

The key verification question is not “did the command run”, but “is live traffic now handled by Nginx processes that include the fix”.

Do not ignore the same Nginx security batch

The 1.30.1 and 1.31.0 releases published by nginx.org on the same day fixed more than CVE-2026-42945. The release information also mentions HTTP/2 request injection, SCGI/uWSGI buffer overread, charset module buffer overread, HTTP/3 address spoofing, OCSP resolver use-after-free, and other issues.

That means production environments should not only add a temporary rule for a single CVE. Treat this Nginx security release as an overall upgrade.

Summary

The key point of CVE-2026-42945 is not “all Nginx instances can be instantly taken over”. It is a long-standing memory safety vulnerability in the rewrite module that can be triggered by unauthenticated requests under specific configurations. The most direct result is worker crash and restart; on weaker environments such as systems with ASLR disabled, code execution risk is higher.

For operations teams, the handling order is straightforward:

Confirm the Nginx source and version.
Check distribution, F5, nginx.org, or cloud-provider advisories.
Upgrade to a fixed version or distribution security package as soon as possible.
Review complex rewrite configuration, especially combinations of $1, $2, and ?.
Confirm ASLR, privilege isolation, and service reload state.

The headline can be scary. The fix should be calm: confirm exposure, upgrade, then clean up high-risk rewrite rules.