A critical vulnerability CVE-2026-42945 (NGINX Rift, CVSS v4 9.2) has been identified in NGINX Plus and NGINX Open Source, in the ngx_http_rewrite_module. It went unnoticed for 18 years and allows remote code execution or denial of service via a non‑authenticated HTTP request. Web servers, reverse proxies, ingress controllers, and WAF solutions built on NGINX are all at risk, and administrators must immediately update versions or change rewrite rule configurations to eliminate unsafe regular expressions.

Technical details of the vulnerabilities

The underlying defect NGINX Rift / CVE-2026-42945 was discovered by researchers from the depthfirst project and is described in detail in their write‑up NGINX Rift. According to F5’s notification for NGINX customers (official F5 advisory), the issue is a heap buffer overflow in the ngx_http_rewrite_module, triggered by a specific combination of directives and regular expressions.

The exploitation conditions for CVE-2026-42945 are as follows:

• the ngx_http_rewrite_module is in use with the rewrite directive,
• it is followed by a rewrite, if, or set directive,
• the rules use unnamed PCRE captures ($1, $2, etc.),
• the replacement string contains the ? character.

A remote, unauthenticated attacker who can send HTTP requests to a vulnerable server can craft a specially formed URI that causes a heap overflow in the NGINX worker process. With ASLR enabled, this is at minimum a reliable way to trigger a worker crash and restart (denial of service). With ASLR disabled, depthfirst and F5 assess that remote code execution in the context of the NGINX process becomes achievable. See also the entry in the NVD: CVE-2026-42945.

The vulnerability is notable because:

• exploitation does not require authentication or prior access;
• a single request is sufficient to trigger the heap overflow;
• the bytes written beyond the allocated block are fully controlled by the attacker via the URI, making the memory corruption targeted rather than random;
• repeated requests can drive worker processes into a crash loop, degrading the availability of all sites on the instance.

According to F5, the vulnerability affects:

• NGINX Plus R32–R36 (fixed in R32 P6 and R36 P4);
• NGINX Open Source 1.0.0–1.30.0 (fixed in 1.30.1 and 1.31.0);
• NGINX Open Source 0.6.27–0.9.7 (no fixes are planned);
• a number of NGINX‑based products: NGINX Instance Manager, F5 WAF for NGINX, NGINX App Protect WAF/DoS, NGINX Gateway Fabric, NGINX Ingress Controller — within specific version ranges listed in the F5 advisory.

Additional vulnerabilities in NGINX

Three other medium and high‑severity vulnerabilities were fixed at the same time:

• CVE-2026-42946 (CVSS v4 8.3) — excessive memory allocation in the ngx_http_scgi_module and ngx_http_uwsgi_module. An unauthenticated attacker capable of intercepting and modifying responses from an upstream server (adversary‑in‑the‑middle) can craft responses that cause NGINX to mishandle worker process memory, leading to reading data from its memory or restarting the process when using the scgi_pass or uwsgi_pass directives. See the advisory for CVE-2026-42946 and the entry CVE-2026-42946.
• CVE-2026-40701 (CVSS v4 6.3) — use-after-free in ngx_http_ssl_module. Condition: ssl_verify_client is set to on or optional, and ssl_ocsp is set to on. This allows a remote unauthenticated attacker to modify data to a limited extent or to cause a worker process restart. See the advisory for CVE-2026-40701 and CVE-2026-40701.
• CVE-2026-42934 (CVSS v4 6.3) — out-of-bounds read in ngx_http_charset_module. There is a risk of disclosing memory contents or restarting a worker when the directives charset, source_charset, charset_map, and proxy_pass are configured together with buffering disabled (off). See the advisory for CVE-2026-42934 and CVE-2026-42934.

The original notifications do not mention any confirmed exploitation of these vulnerabilities in real‑world attacks, but the technical profile of CVE-2026-42945 makes it an attractive target for automation and mass scanning.

Context and threat specifics

NGINX is traditionally used as a high‑load web server and reverse proxy, as well as the basis for ingress controllers in Kubernetes and F5 commercial solutions. The bug in the rewrite mechanism, present since early versions (0.6.x), clearly illustrates the risks of “edge” logic: unusual combinations of directives, integration with PCRE, and complex URI templates historically receive less testing, yet are widely used in real configurations.

Critically, the vulnerable code path is reached before any application authentication checks or business logic. In effect, NGINX itself becomes the attack surface here. This increases the value of the vulnerability to attackers: only network‑level access to the HTTP port is required, even if a well‑protected backend is hidden behind NGINX.

The additional vulnerabilities (SCGI/UWSGI, SSL, charset) illustrate another class of problems: when NGINX trusts content from the upstream server or from the certificate validation infrastructure (OCSP), processing errors in this data can push execution beyond expected memory boundaries. In scenarios where an attacker controls or can tamper with upstream responses, such flaws become powerful tools for reading memory fragments or taking services offline.

Impact assessment

The highest‑risk environments are:

• organizations using NGINX as a public‑facing web server or reverse proxy with the ngx_http_rewrite_module enabled, especially where there are many complex rules;
• clouds and hosting providers where a single NGINX instance serves multiple tenants: successful exploitation of CVE-2026-42945 can affect all customers on that host;
• Kubernetes clusters with NGINX Ingress Controller, as well as deployments of NGINX App Protect WAF/DoS and NGINX Gateway Fabric in vulnerable versions;
• systems where ASLR is disabled or weakened (for example, specialized appliances or environments heavily optimized for performance).

If no response measures are taken, the following consequences are possible:

• full host compromise via RCE in the NGINX process (CVE-2026-42945), followed by lateral movement within the network;
• compromise of confidential data by reading fragments of worker process memory (CVE-2026-42946, CVE-2026-42934), which may contain tokens, cookies, and parts of requests and responses;
• widespread denial of service — worker processes crashing in a loop, websites and APIs becoming unavailable, increased latency, and 502/504 errors;
• indirect losses: reputational damage, SLA violations, and potential fines for personal data leakage.

Practical recommendations

1. Prioritization and timelines

• Treat CVE-2026-42945 as critical: updating or applying a workaround should be prioritized as “immediate/within the next few hours” on publicly accessible hosts.
• The other vulnerabilities (CVE-2026-42946, CVE-2026-40701, CVE-2026-42934) have a “high” priority; schedule updates for the next maintenance window.

2. Updating to fixed versions

• For NGINX Plus, update to at least R32 P6 or R36 P4, or newer releases that include the fixes (see the F5 advisory).
• For NGINX Open Source, upgrade to 1.30.1 or 1.31.0 and above.
• For NGINX‑based products (Ingress Controller, App Protect WAF/DoS, Gateway Fabric, Instance Manager, F5 WAF for NGINX), map current versions against the ranges listed in the corresponding F5 advisories and update to the recommended releases.
• For very old 0.6.27–0.9.7 branches where no fixes are planned, the only option is to migrate to supported versions.

3. Workaround for CVE-2026-42945

If an immediate update is not possible, it is recommended to change rewrite rule configurations as described by F5 and depthfirst:

• Find all rewrite directives that are followed by rewrite, if, or set, where:
  • unnamed captures like $1, $2, etc. are used;
  • the replacement string contains the ? character.
• Redefine the regular expressions to use named PCRE captures, for example:
  • before: rewrite ^/user/(\d+)\?(.*)$ /profile.php?id=$1?$2;
  • after: rewrite ^/user/(?<uid>\d+)\?(?<rest>.*)$ /profile.php?id=$uid?$rest;
• After making changes, verify that redirect functionality is preserved and restart NGINX.

The essence of the workaround is that converting unnamed captures to named ones changes the data handling path in NGINX’s code and removes the vulnerable scenario.

4. Reducing risk from the additional vulnerabilities

Until you update, you can temporarily reduce the attack surface:

• For CVE-2026-42946: where possible, limit or temporarily disable scgi_pass and uwsgi_pass on external boundaries, especially where the upstream may be controlled by third parties.
• For CVE-2026-40701: if client verification and OCSP are not critically important, consider temporarily disabling ssl_ocsp on or relaxing ssl_verify_client, while assessing the impact on client authentication requirements.
• For CVE-2026-42934: minimize the use of charset_map in combination with proxy_pass and disabled buffering if this can be done without harming business requirements.

5. Checking exposure and monitoring

• Check the NGINX version with the command nginx -v and compare it with the vulnerable version ranges.
• Analyze the configuration:
  • search nginx.conf and included files for the keywords rewrite, $1, $2, ?;
  • identify rules matching the pattern described above.
• Enable or increase NGINX error logging and system logging:
  • watch for repeated worker process crashes, segmentation fault signals, and cyclic restarts;
  • correlate these events with suspicious HTTP requests containing unusual URIs with ? and complex patterns.
• Ensure ASLR is enabled at the operating system level on servers as an additional barrier against RCE, even after patches are applied.

The key action for owners of NGINX‑based infrastructure is to update NGINX Plus, NGINX Open Source, and related products as quickly as possible to versions that fix CVE-2026-42945 and the associated vulnerabilities. If updates are delayed, immediately review rewrite rules and replace unnamed captures with named ones in all configurations exposed to the internet.