2026 05 13 Nginx Rift Cve 2026 42945

A heap-based buffer overflow in nginx’s ngx_http_rewrite_module , disclosed today as CVE-2026-42945 and nicknamed NGINX Rift , allows an unauthenticated attacker to crash a worker process, or potentially achieve remote code execution on hosts with ASLR disabled, by sending a single crafted HTTP request. The flaw has been in the rewrite module for roughly 18 years and affects every version of nginx Open Source from 0.6.27 through 1.30.0, as well as nginx Plus R32 through R36.

The bug is a size-mismatch between two passes over the rewrite replacement string. When a rewrite directive uses an unnamed PCRE capture ( $1 , $2 , and so on) with a replacement that contains a question mark, and is followed by another rewrite , if , or set directive, nginx computes the destination buffer size using one escaping method but writes the result using a different one. Characters such as + , % , and & expand during re-escaping, and the write runs past the end of the allocation. The bytes written past the buffer are derived from the attacker’s URI, which is what makes corruption controllable rather than purely a crash. F5 rates the issue CVSS 4.0 9.2 (Critical) / CVSS 3.1 8.1 (High), CWE-122.

If you operate an internet-facing nginx instance, especially one with non-trivial rewrite rules in front of a PHP or application backend, this matters today.

More information the vulnerability:

Our team independently reproduced the issue and built a proof of concept against the nginx packages on every supported AlmaLinux release. The denial-of-service path is trivial on all of them: a single crafted request reliably crashes the targeted worker process on AlmaLinux 8, 9, 10, and Kitten 10.

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 (which is the default on every supported AlmaLinux release) we do not expect a generic, reliable exploit to be easy to produce. 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.

Security is a top priority at AlmaLinux, and given how trivially the worker-crash DoS reproduces against every supported release, we did not want to wait. Patches are not yet available from Red Hat , so our core team has built patched nginx packages using the upstream fix from nginx 1.31.0 / 1.30.1, backported and adapted to the nginx versions we ship on each supported AlmaLinux branch. The decision to ship these ahead of a CentOS Stream / RHEL update was made by our technical steering committee, ALESCo .

These packages are available in the testing repository today . After the community has helped verify them, we will release them to the production repositories. This blog post will be updated when that happens.

It only takes a few steps to install and test the patched nginx package from the testing repo.

Install the testing repo

Restart nginx to load the new binary

Confirm you are running the patched build

We don’t recommend keeping the testing repo enabled after you’ve updated, unless you’ve done this on a truly non-production environment. If this is a production environment, you can disable the repo with this command:

If you encounter problems, please let us know as soon as you can, either in AlmaLinux chat or on bugs.almalinux.org .

AlmaLinux 8 and 9 ship multiple nginx versions through DNF module streams ( nginx:1.20 , nginx:1.22 , nginx:1.24 , and so on). Patched builds are being published for every supported stream on each release. If you have a stream enabled, the standard dnf upgrade nginx command above will pick up the patched build for that stream once metadata is refreshed. You can confirm which stream you are on with:

AlmaLinux Kitten 10 does not have a separate testing repository. The patched nginx is shipping directly to Kitten’s regular repository, so there is nothing extra to enable. Just upgrade and restart:

All supported AlmaLinux releases (8, 9, 10) ship an nginx version in the affected range and are vulnerable in their default configuration only if a vulnerable rewrite pattern is present . nginx with no rewrite directives, or with rewrites that use named captures ( (? ...) ) or that do not put a ? in the replacement string, is not exploitable through this code path. That said, the vulnerable pattern is common in real-world configurations (PHP front controllers, WordPress permalinks, API gateways), so we recommend updating regardless.

Patched nginx versions in AlmaLinux:

The non-default nginx module streams on AlmaLinux 8 and 9 ( nginx:1.22 , nginx:1.24 , and so on) are also being rebuilt with the fix. Those NVRs will be added here as the builds land in the testing repository. If you have enabled a non-default stream, watch this post for the patched version, or check dnf info nginx after a dnf clean metadata once your stream’s update is published.

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. The condition that has to hold for a rewrite to be exploitable is:

Removing any one of those conditions is enough. The cleanest approach is to switch from unnamed captures to named captures, which sidesteps the buggy code path entirely.

Mitigated pattern using named captures:

After editing, validate the config and reload nginx:

If you maintain a complex set of vhosts, this grep will surface the rewrites you most likely need to look at first. It looks for rewrite lines that reference an unnamed capture and contain a ? :

Review each hit and either convert it to named captures or restructure so there is no following rewrite , if , or set directive in the same context. This is a stopgap. The right fix is to install the patched package and restart nginx.

Thanks to the researchers at depthfirst for finding, writing up, and responsibly disclosing this vulnerability, and to the nginx team at F5 for shipping the upstream fix in nginx 1.31.0 / 1.30.1.

Thanks to the AlmaLinux infrastructure team for turning around patched builds for every supported release and stream on disclosure day, and to ALESCo for prioritizing this work. And thank you in advance to everyone in the community who helps us test these packages. That’s the part that gets them safely into production.