OSG-SEC-2026-05-21 HIGH Nginx Vulnerability ngx_http_rewrite_module

Dear OSG Security Contacts,

There is a HIGH risk vulnerability concerning "nginx" module "ngx_http_rewrite_module" used by many webservices. It is extensively described at the links in references.

IMPACTED VERSIONS:

NGINX Open Source
- Versions 1.0.0 through 1.30.0: Update to version 1.30.1, 1.31.0, or later
- Legacy versions 0.6.27 through 0.9.7: No official patch is planned; manual configuration changes are required to mitigate the risk

NGINX Plus
- Release 36 (R36 to R36 P3): Update to R36 P4
- Release 32 (R32 to R32 P5): Update to R32 P6
- Releases 33, 34, and 35: No direct patch; you must upgrade to R36 P4 or R37.0.0 (or higher)

WHAT ARE THE VULNERABILITIES:

NGINX Plus and NGINX Open Source have a vulnerability in the ngx_http_rewrite_module module. The issue occurs when:
- a rewrite directive uses unnamed PCRE captures (e.g., $1, $2)
- the replacement string contains a ?
- and the directive is followed in the same context by another rewrite, if, or set directive

An unauthenticated attacker along with conditions beyond its control can exploit this vulnerability by sending crafted HTTP requests. This may cause a heap buffer overflow in the NGINX worker process leading to a restart.
Additionally, for systems with Address Space Layout Randomization (ASLR) disabled, code execution may also be possible.

WHAT YOU SHOULD DO:

Sites running affected nginx versions are strongly encouraged to apply vendor patches or upgrade to fixed releases as soon as possible. If immediate patching is not possible, review nginx rewrite rules for vulnerable patterns and modify configurations accordingly.

The condition that has to hold for a rewrite to be exploitable is:
- The rewrite uses an unnamed PCRE capture in the replacement ($1, $2, …), and
- The replacement string contains a ?, and
- The rewrite is followed in the same context by another rewrite, if, or set directive.
Removing any one of these conditions mitigates the vulnerable code path. The cleanest approach is to switch from unnamed captures to named captures, which sidesteps the buggy code path entirely.

Replace unnamed captures ($1, $2) with named captures in every affected rewrite directive. Vulnerable pattern:

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

Example mitigated pattern:

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

REFERENCES

https://almalinux.org/blog/2026-05-13-nginx-rift-cve-2026-42945/

https://access.redhat.com/security/cve/cve-2026-42945

https://security-tracker.debian.org/tracker/CVE-2026-42945

https://ubuntu.com/security/notices/USN-8271-1

https://www.akamai.com/blog/security-research/nginx-critical-heap-buffer-overflow-cve-2026-42945

https://www.regular-expressions.info/named.html

https://depthfirst.com/nginx-rift

Please contact the OSG security team at [email protected] if you have any questions or concerns.

OSG Security Team