Notifications
Clear all
Topic starter
02/08/2026 11:35 am
TL;DR: NGINX Rift, a CVE-2026-42945 heap overflow in ngx_http_rewrite_module, lets unauthenticated attackers trigger remote code execution or denial of service on exposed NGINX instances configured with set or rewrite directives, according to OXSecurity. The disclosure shows that inventory, exposure validation, and exploitability testing now matter as much as patching speed in critical web infrastructure.
NHIMG editorial — based on content published by OXSecurity: NGINX Rift and exposed NGINX instances
By the numbers:
- CVE-2026-42945 carries a CVSS score of 9.2 (Critical).
- NGINX Open Source 1.0.0 through 1.30.0 are affected, with fixed versions 1.30.1 and 1.31.0.
Questions worth separating out
Q: What breaks when vulnerable NGINX rewrite logic is exposed to the internet?
A: The main failure mode is that specially crafted HTTP requests can trigger heap corruption inside the rewrite engine.
Q: Why does runtime exposure matter more than a vulnerable image in a repository?
A: Because risk begins when a vulnerable binary is both loaded and reachable.
Q: How do security teams know whether an NGINX deployment is exposed to this issue?
A: Check for affected versions and inspect configuration for rewrite, if, and set directives that use unnamed captures.
Practitioner guidance
- Patch exposed NGINX instances first Prioritise any deployment in the affected version ranges, starting with internet-facing ingress, reverse proxies, and edge appliances.
- Audit infrastructure as code and base images Search Dockerfiles, Helm charts, Terraform modules, and container layers for pinned NGINX versions such as 1.29.x and 1.30.0, then replace them with fixed versions before the next build promotes them.
- Correlate runtime inventory with public ingress Compare live NGINX fingerprints against public entry points so you can see which workloads are both vulnerable and reachable.
What's in the full analysis
OXSecurity's full article covers the operational detail this post intentionally leaves for the source:
- Exact affected version ranges across NGINX Open Source, NGINX Plus, and adjacent F5 and NGINX products
- Four-part detection workflow covering blocking new usage, finding existing instances, confirming exposure, and proving exploitability
- Detailed examples of where vulnerable NGINX appears in Dockerfiles, Terraform modules, Helm charts, and runtime layers
- Product-specific screenshots and dashboard workflows showing how the issue is surfaced in OXSecurity's tooling
👉 Read OXSecurity's analysis of NGINX Rift and exposed NGINX instances →
NGINX Rift: are your controls catching exposed instances fast enough?
Explore further
02/08/2026 12:49 pm
NGINX exposure management has become an identity-adjacent control problem, not only a patching problem. Once a public edge service can be turned into code execution, the attacker is no longer attacking only the application layer. They are entering the environment through the same path that later supports secret theft and session abuse. That means platform teams and identity teams both have a stake in the control plane around exposed runtime services.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, according to The State of Non-Human Identity Security.
A question worth separating out:
Q: Who is accountable when exposed edge infrastructure stays vulnerable after disclosure?
A: Accountability sits across platform, application, and security ownership, because the failure spans code, runtime, and exposure management. Frameworks such as NIST CSF and NIST SP 800-53 expect asset inventory, secure configuration, and timely remediation. If a vulnerable edge service remains reachable, ownership should be explicit rather than shared loosely.
👉 Read our full editorial: NGINX Rift exposes how unauthenticated RCE becomes enterprise risk
