NGINX Rift (CVE-2026-42945) Patches Released

Update: Patched nginx is now in production

2026-05-14 22:41 UTC: Patched nginx packages are now rolling out to the AlmaLinux production repositories for every supported release. This covers the default nginx package on AlmaLinux 8, 9, 10, and Kitten 10, and every nginx module stream we ship on AlmaLinux 8 (nginx:1.16, nginx:1.18, nginx:1.20, nginx:1.22, nginx:1.24) and AlmaLinux 9 (nginx:1.24, nginx:1.26). You no longer need to enable the testing repo. Just run:

sudo dnf clean metadata && sudo dnf upgrade nginx
sudo systemctl restart nginx

Most mirrors have a sync frequency of 3 hours. If the update is not available to you yet, try again in about an hour. Confirm you are running the patched build with rpm -q nginx against the NVRs listed in the affected versions section further down.

The default-stream packages released to production are bit for bit identical to those that spent yesterday in the testing repository. The module-stream packages, including the end-of-life AlmaLinux 8 streams nginx:1.16, nginx:1.18, nginx:1.20, and nginx:1.22, were pushed directly to production without staging in testing. We chose to do that given the severity of the vulnerability and the fact that those streams are end of life upstream and will not receive a fix from Red Hat. See the Patching ahead of our upstream section for the full rationale.

The testing-repo instructions further down in this post remain for reference but are no longer the recommended path. We’d like to thank everyone in the community who helped verify the default-stream packages in testing yesterday.

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 about the vulnerability:

• NVD entry: https://nvd.nist.gov/vuln/detail/CVE-2026-42945
• F5 advisory K000161019: https://my.f5.com/manage/s/article/K000161019
• Researcher write-up (depthfirst): https://depthfirst.com/nginx-rift

What we’ve verified

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.

Patching ahead of our upstream

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.

We also went further than we expect upstream to. Of the nginx module streams we ship, we expect Red Hat to patch only the streams that are currently supported upstream: nginx:1.24 on AlmaLinux 8, and nginx:1.24 and nginx:1.26 on AlmaLinux 9. The earlier streams (nginx:1.16, nginx:1.18, nginx:1.20, and nginx:1.22 on AlmaLinux 8) reached end of life some time ago and would normally receive no further fixes. Given the severity of NGINX Rift, ALESCo chose to backport the fix to every one of those end-of-life streams as well, so users who have not yet been able to migrate to a supported stream still have a path to a patched nginx without changing their module configuration.

The default-stream packages first landed in the AlmaLinux testing repository on 2026-05-13 for community verification. The module-stream packages, including the end-of-life streams above, were built directly against the production repositories on 2026-05-14 without a separate testing-repo staging step. The end-of-life streams in particular have a small enough audience that staging in testing would not have produced meaningful verification coverage, and we judged that getting the fix into the hands of those users quickly was the right tradeoff. All of these packages are now in production.

Installing from the testing repository (historical, for reference)

The instructions in this section are preserved from when the default-stream packages were staged in testing on 2026-05-13. As of 2026-05-14 22:41 UTC the packages are in the production repositories and the simple dnf upgrade nginx flow at the top of this post is the recommended path. The testing-repo flow below still works but is no longer necessary.

Install the testing repo

sudo dnf install -y almalinux-release-testing

Upgrade nginx

sudo dnf upgrade nginx --enablerepo=almalinux-testing

Restart nginx to load the new binary

sudo systemctl restart nginx

Confirm you are running the patched build

nginx -v
rpm -q nginx

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:

sudo dnf config-manager --disable almalinux-testing

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

A note for users of the nginx module streams

AlmaLinux 8 and 9 also ship multiple nginx versions through DNF module streams. Patched builds for every stream we ship, including streams that are end of life upstream, are now in the production repositories alongside the default packages. The streams covered are nginx:1.16, nginx:1.18, nginx:1.20, nginx:1.22, and nginx:1.24 on AlmaLinux 8 (only nginx:1.24 is still supported upstream), and nginx:1.24 and nginx:1.26 on AlmaLinux 9. If you have a non-default stream enabled, the standard dnf upgrade nginx command at the top of this post will pick up the patched build for your stream once metadata is refreshed. You can confirm which stream you are on with:

sudo dnf module list nginx

Affected versions and patched packages

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 ((?<name>...)) 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 module-stream builds have an automatically generated module suffix in the dist tag (.module_el8.X.X+XXXXX+XXXXXXXX) that varies per build, so the version-release values below are listed without the module suffix. Anything matching the version and an equal or higher release on a given stream contains the fix:

AlmaLinux 8

• Default (regular package): nginx-1.14.1-9.el8.10.alma.1 and above
• nginx:1.16 stream: nginx-1.16.1-2.1.el8.10.alma.1 and above
• nginx:1.18 stream: nginx-1.18.0-3.1.el8.10.alma.1 and above
• nginx:1.20 stream: nginx-1.20.1-1.1.el8.10.alma.2 and above
• nginx:1.22 stream: nginx-1.22.1-1.1.el8.10.alma.2 and above
• nginx:1.24 stream: nginx-1.24.0-3.el8.10.alma.2 and above

AlmaLinux 9

• Default (regular package): nginx-1.20.1-24.el9_7.2.alma.2 and above
• nginx:1.24 stream: nginx-1.24.0-5.2.alma.1 and above
• nginx:1.26 stream: nginx-1.26.3-2.1.alma.1 and above

AlmaLinux 10 and Kitten 10

• nginx-1.26.3-2.el10_1.1.alma.1 and above

Temporary mitigation: rewrite your rewrites

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:

1. The rewrite uses an unnamed PCRE capture in the replacement ($1, $2, …), and
2. The replacement string contains a ?, and
3. The rewrite is followed in the same context by another rewrite, if, or set directive.

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.

Vulnerable pattern:

rewrite ^/users/([0-9]+)/profile/(.*)$ /profile.php?id=$1&tab=$2 last;

Mitigated pattern using named captures:

rewrite ^/users/(?<user_id>[0-9]+)/profile/(?<section>.*)$ /profile.php?id=$user_id&tab=$section last;

After editing, validate the config and reload nginx:

sudo nginx -t
sudo systemctl 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 ?:

sudo grep -RnE 'rewrite[[:space:]].*\$[0-9].*\?' /etc/nginx

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

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 to everyone in the community who helped verify the default-stream packages in the testing repository yesterday. That’s the part that got them safely into production.

Stay informed

Remaining aware of these vulnerabilities and acting quickly can keep your system and data safe. Follow the AlmaLinux Blog, join the Mattermost Community Chat, and subscribe to Announce and Security mailing lists to stay informed and updated.

Changelog

• 2026-05-14 22:41 UTC: Patches released to the AlmaLinux production repositories. This covers the default nginx package on every supported release and every nginx module stream on AlmaLinux 8 (nginx:1.16, nginx:1.18, nginx:1.20, nginx:1.22, nginx:1.24) and AlmaLinux 9 (nginx:1.24, nginx:1.26). The default-stream packages graduated from testing; the module-stream packages, including the end-of-life AlmaLinux 8 streams, were built directly to production without a separate testing-repo staging step. Update notice added at the top of the post and title updated to reflect release.

• 2026-05-13: Initial publication. Patched default-stream nginx packages staged in the testing repository for AlmaLinux 8, 9, 10, and Kitten 10 for community verification.