NGINX Rift CVE-2026-42945 — how an 18-year-old assumption in the rewrite module rips through the reverse proxy

TL;DR — 90 seconds

An 18-year-old assumption in the NGINX rewrite module lets a single crafted HTTP request trigger a worker crash; with ASLR off, potential RCE is on the table. The patch landed two days ago, and the configuration discipline across the NGINX estate is the second, more durable mitigation.

What is the problem?

NGINX' ngx_http_rewrite_module rewrites URLs against regex patterns. A typical configuration looks like this: rewrite ^/old/(.+)$ /new/$1?token=abc;. The unnamed capture $1 picks up the first capture block from the regex and inserts it into the replacement string. The question mark marks the start of the query string in the replacement.

The security path sits in the two-stage buffer handling. NGINX calculates the buffer size required for the finished replacement string with a first escaping pass. It then writes the replacement with a second escaping pass into the allocated buffer — with a slightly different set of special characters.

If the replacement contains characters such as +, % or & and meets a follow-up directive (rewrite, if, set) that processes the replacement again, the re-escape expands the string: + becomes %20, & becomes &, and the write path writes more bytes than the sizing path allocated. The buffer overflow runs into the heap area beyond the end of the allocation.

The Picus Security analysis traces the path in detail: the calculation runs in ngx_http_script_regex_end_code() with ngx_escape_uri(NULL, ...), the write in ngx_http_script_complex_value_code() with ngx_escape_html(NULL, ...). Both functions have been implemented this way in NGINX since 0.6.27 (2008); the discrepancy in the special-character set has not led to a security flaw for 18 years because typical configurations either do not use unnamed captures with question-mark replacements, or because the follow-up directive did not trigger the re-escape.

This is the structural lesson: not a new code path, but an old assumption about consistency between two internal functions that becomes sharp for a particular configuration class only through the combination of three conditions (unnamed capture + question mark + follow-up directive). The exploit PoC in the public repository on GitHub shows the reproduction in five lines of configuration and a curl call.

Who is affected?

A compact overview of affected and non-affected configurations.

Anyone running TYPO3 or Sylius platforms in the German Mittelstand via an NGINX reverse proxy on Hetzner Cloud, Hetzner Dedicated, AWS EC2 or Azure VMs is affected by default — the share of platforms without a rewrite directive in the NGINX path is small in the DACH corpus. We treat the estate operationally as “patch NGINX and lint the config” and follow the audit path: configuration lint first, then version audit, then patch in the maintenance window.

Impact

The operational severity is set by three factors: the trigger cost (unauthenticated, one HTTP request), the exposure surface (NGINX as front edge), and the exploit-realisation stage (worker crash guaranteed, RCE conditional).

The trigger cost is low. The attacker needs no account, no session, no token. A single HTTP request against a path that falls under a vulnerable rewrite directive is enough. That makes the finding different from the Composer token leak (a local pipeline detail) and the node-ipc incident (a local build pipeline detail): NGINX Rift sits on the internet-facing frontline.

The exposure surface is wide. By the latest available W3Techs estimates, NGINX serves a low-30s percentage range of global web-server load and is the most common reverse proxy in front of TYPO3/Sylius in the German Mittelstand PHP estate. The real distribution pattern is not standalone NGINX hosts but NGINX configuration templates across the platform estate, the majority of which use rewrite directives with unnamed captures — the standard path is rewrite ^/old/(.+)$ /new/$1?token=..., and the token pattern contains special characters such as + or &.

The exploit-realisation stage is asymmetric. Worker crash is guaranteed: the heap overflow hits the current worker, NGINX restarts the worker automatically, but the crash is observable and costs availability. RCE is conditional: on hosts with ASLR disabled, the heap-spray technique from the PoC repository is directly usable; on hosts with ASLR enabled, exploitation is considerably more involved. In the German Mittelstand estate, ASLR is on by default on modern Linux distros (Debian 12+, RHEL 9+, Ubuntu 22.04+); on older legacy hosts (Debian 10/11, CentOS 7, Ubuntu 18.04) the configuration is uneven.

Business impact of a successful exploit on a tenant platform is in the worst case the front-edge takeover: anyone who gains NGINX worker RCE sits on the TLS endpoint, on the reverse-proxy layer and therefore above the tenant PHP layer. That is the lead-in for man-in-the-middle against tenant users, persistent backdoor installation in the NGINX configuration path, or lateral movement into the PHP backend behind it. In the simpler case the impact is a recurring DoS wave that disrupts the tenant platform without compromising the backend stack.

Mitigation / immediate actions

Three paths, depending on platform discipline.

Path 1 — Patch to the fixed line

Distribution patches have been rolled out since 13 May 2026. AlmaLinux has the patched line in the testing channel, Debian security updates are flowing, NGINX Plus ships directly through the official repo.

# Debian / Ubuntu — security update with distro backport
sudo apt update
sudo apt install --only-upgrade nginx
nginx -v
# expected: nginx version: nginx/1.30.1 (or distro backport state)

# RHEL / AlmaLinux / Rocky — via the nginx stream module
sudo dnf module reset nginx
sudo dnf module enable nginx:1.30
sudo dnf update nginx

# NGINX Plus through the official repo
sudo apt update
sudo apt install nginx-plus
nginx -v
# expected: nginx version: nginx/1.27.5 (nginx-plus-r36-p1)

After the update, reload NGINX rather than restart — reload lets open connections finish cleanly while the new workers already start with the patch.

sudo systemctl reload nginx
# or
sudo nginx -s reload

Path 2 — Configuration lint against the trigger conditions

The patch closes the code path, but the structural vulnerability remains in the configuration. A rewrite directive with an unnamed capture, a question-mark replacement and a follow-up directive remains a fragile configuration path even after the patch, capable of triggering similar findings in the future. Linting in the platform template is the more durable mitigation.

# Search for the risky pattern across all NGINX configuration files
sudo grep -rEHn 'rewrite.*\$[0-9]+.*\?' /etc/nginx/ \
  | grep -v '^[[:space:]]*#'

When a hit appears, replace the unnamed capture ($1, $2) with a named capture using the (?<name>…) syntax.

# Before (risky)
location /old/ {
    rewrite ^/old/(.+)$ /new/$1?token=abc;
}

# After (lint-safe)
location /old/ {
    rewrite ^/old/(?<path>.+)$ /new/$path?token=abc;
}

Named captures run through both escaping functions identically. The sizing path and the write path are consistent, and the heap-overflow path is closed.

Path 3 — WAF layer as a protection line for unpatched hosts

If the patch cannot land in the 24-hour maintenance window (for example because a platform migration is in flight), the trigger condition can be blunted at the WAF layer. The PoC repository shows a specific request pattern that triggers the exploit chain. A WAF rule on the Cloudflare edge, AWS WAF or a ModSecurity front can catch requests with conspicuous path parameters (+, %, & in URL path segments combined with query-string manipulation).

# Example: ModSecurity rule as a stopgap
SecRule REQUEST_URI "@rx (\+|\%|\&).*\?.*\$" \
    "id:90042945,phase:1,deny,log,msg:'CVE-2026-42945 trigger pattern',\
     tag:'CVE-2026-42945'"

A WAF layer is not a substitute for the patch. It catches the currently known exploit pattern but not necessarily future variants in the same class. It buys time until the maintenance window is through.

Detection / verification

Three complementary paths.

Path 1 — Version audit across the NGINX estate

First layer: a version inventory across the entire tenant estate.

# Collect the nginx version on all hosts via Ansible, Puppet or a custom audit script
ansible all -m shell -a "nginx -v 2>&1" --become

# Filter out hits on unpatched versions
ansible-playbook nginx-version-audit.yml \
  --extra-vars "fail_below=1.30.1"

For Kubernetes ingress estates, additionally check the ingress controller image tags:

# ingress-nginx image version on all clusters
kubectl get pods -A -l app.kubernetes.io/name=ingress-nginx \
  -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name}: {.spec.containers[0].image}{"\n"}{end}'

# expected: registry.k8s.io/ingress-nginx/controller:v1.13.x or newer

Path 2 — Configuration audit on the trigger pattern

The second layer is the configuration lint from mitigation path 2 — but as a systematic audit across the entire NGINX estate, not a single-host run.

# Audit script across all NGINX hosts in the platform
for host in $(ansible-inventory --list | jq -r '.all.hosts[]'); do
  echo "## Host: $host"
  ssh "$host" "sudo grep -rEHn 'rewrite.*\\\$[0-9]+.*\\?' /etc/nginx/ 2>/dev/null \
    | grep -v '^[[:space:]]*#' | head -20"
done

Sort hit hosts into a separate patch cohort — they need patch plus configuration lint, not just patch.

Path 3 — Access-log audit on the exploit pattern

When the platform runs access logs with query-string retention (the standard for TYPO3 and Sylius platforms under tenant audit obligation), the exploit pattern can be checked retrospectively.

# Access-log search for the typical exploit pattern
sudo grep -E '"[A-Z]+ [^"]*[\+\%\&][^"]*\?[^"]*HTTP' /var/log/nginx/access.log \
  | awk '{print $1, $4, $5, $7}' \
  | sort -u

Path 4 (optional) — Falco rule for NGINX worker crashes

Worker crashes from the heap overflow show up in dmesg and the NGINX error log. A Falco rule picks up the correlation.

# /etc/falco/rules.d/nginx-rift-detection.yaml
- rule: NGINX worker process killed by signal SEGV
  desc: NGINX worker exited with SIGSEGV — possible CVE-2026-42945 exploitation
  condition: >
    spawned_process and
    proc.pname = "nginx" and
    proc.exepath endswith "nginx" and
    evt.type = procexit and
    proc.exitcode = -11
  output: >
    NGINX worker SIGSEGV: pid=%proc.pid cmdline=%proc.cmdline
  priority: WARNING
  tags: [nginx, cve-2026-42945, segfault]

The reproduction is documented in the public repository on GitHub: five lines of configuration, a curl call, a worker crash. On an isolated test host (separate VM, no tenant traffic, ASLR explicitly disabled for the full path or enabled for the DoS path) the finding can be reproduced. Do not run it on a production NGINX — the worker crash takes open tenant connections down with it.

Operator recommendation

The operational question is not “do we patch to 1.30.1?” but “in which maintenance window and in which order?”. The patch has been available for two days, the PoC has been public since yesterday — the window for unnoticed mass exploitation opens today, Friday, with the weekend ahead.

Operational Decision Block — patch now vs. config lint

• Patch immediately when the NGINX configuration contains a rewrite directive with an unnamed capture ($1, $2) plus a question mark plus a follow-up directive, and the host is internet-facing.
• Deploy a WAF stopgap when the maintenance window for the patch does not land within the next 48 hours — the WAF rule from mitigation path 3 protects for a limited time.
• Config lint plus patch in the standard cycle when the NGINX configuration uses only named captures or no rewrite directives with captures at all — the patch is still mandatory, but the maintenance window can fit the standard weekly cadence.
• Awareness only when the platform uses NGINX purely for TLS termination without rewrite directives and the backend (Apache, Caddy, a custom PHP-FPM listener setup) handles the path itself.

German Mittelstand

Patch to nginx 1.30.1 via the distribution patch mechanism (apt, dnf) in the standard weekly maintenance window. Run a configuration lint across the tenant NGINX configurations — replace unnamed captures with named ones, check question-mark replacements for consistency, review set directives after rewrite for structural necessity. Add a linting rule to the platform configuration template so future tenant configs do not reintroduce the pattern. Activate the WAF layer (Cloudflare, AWS WAF, ModSecurity) as a stopgap only when the patch slips by more than 48 hours.

Enterprise

In addition to the Mittelstand line: a pre-receive hook on the central NGINX configuration repository that marks unnamed captures with question-mark replacements as a hard block. Patch NGINX Plus to R36 P1 via the official repo (R32 P2 / R33 P3 / R34 P3 / R35 P2 / R36 P1 are the current patch lines depending on platform inventory). Access-log audit on the exploit pattern across the last seven days retrospectively; on hits, tenant-scoped reconstruction of the affected requests. WAF front-edge rule as default, not stopgap — the pattern-filter layer belongs in an enterprise platform as a fixed component.

Kubernetes platform

If you run NGINX as an ingress controller on Kubernetes platforms (ingress-nginx, NGINX Ingress, Tekton-driven platforms), patch the ingress controller via the Helm chart pin to the patched image line. Helm chart pin to ingress-nginx-v1.13.x or newer (NGINX Ingress 5.0+ accordingly). Audit snippet annotations (nginx.ingress.kubernetes.io/server-snippet, nginx.ingress.kubernetes.io/configuration-snippet) against the rewrite pattern — use named captures here too, not $1. Roll out the Falco rule for NGINX worker SIGSEGV cluster-wide so crash patterns over the weekend are not missed.

• Sub-scenario ingress-nginx with tenant-specific snippets: snippet audit per tenant, because rewrite directives are tenant-scoped and the lint produces tenant-specific hits.
• Sub-scenario service mesh with NGINX sidecar: when Istio/Linkerd run with an NGINX-based egress sidecar (rare, but present in the DACH estate), raise the sidecar image to the patched line.

Declarative stacks (NixOS / Talos / Flatcar / Wolfi)

Update the NixOS modules for nginx once the nixpkgs bump to 1.30.1 is merged (as of 15 May: the PR is merged into nixos-unstable, channel sync in progress). Wolfi-based nginx packages pick up the patch through the apk index update for the current week — image rebuild on Wolfi base with apk upgrade nginx, Helm chart pin to the new image tag, cluster rollout in the standard maintenance window. Self-hosted edge hosts on Talos or Flatcar base inherit the patch with image promotion; declarative stacks have the advantage that the configuration template can be subjected to the lint at the same time — the NixOS module wrapper for services.nginx can enforce the named-capture pattern directly.

What we actually did

We ran four disciplines on 14 May 2026 between 16:00 and 20:00 CEST and on 15 May 2026 between 09:00 and 13:00 CEST.

First the configuration lint: scanned every NGINX configuration in the tenant platforms via a central audit script. 23 NGINX hosts across 17 tenant platforms, 19 of them with rewrite directives in the active configuration. 14 hosts had unnamed captures, 11 of those with question marks in the replacement, 8 of those with a follow-up set or rewrite directive. Eight directly vulnerable configuration points across five tenant platforms — all in TYPO3 backend-locking patterns or Sylius multi-channel routing.

Then the configuration pin to named captures: rewrote all eight points to named captures ((?<path>.+) instead of (.+) with $1). Merged the platform team's pull requests in cohorts (2 tenants per cohort), each with a smoke test against the live tenant URL that verifies rewrite-path consistency. One tenant required a two-stage migration maintenance window because the Sylius channel routing contained several nested rewrites and the smoke test returned a path regression hit — we landed that configuration change at 12:00 CEST on 15 May.

Then the patch rollout: lifted all 23 NGINX hosts to nginx 1.30.1 via the distro patch path. The 17 hosts on Debian 12 had the backport available from the evening of 13 May in the security updates stream; the 5 hosts on AlmaLinux 9 received the backport from the testing channel via an explicit dnf install from the nginx:1.30 module; a single host on NGINX Plus R34 received the nginx-plus-r34-p3 update from the official NGINX repo. Patch cohorts of three hosts with a 15-minute observation window in which tenant platform health checks ran in parallel.

Finally the detection stage: activated the Falco rule NGINX worker process killed by signal SEGV on the 23 hosts. Added the WAF rule pattern on the Cloudflare edge hosts of the three platforms that sit behind Cloudflare — as a default layer, not a stopgap. Ran an access-log audit on the exploit pattern across the last seven days retrospectively — no hits, the pattern has not appeared in tenant traffic in mass-exploit mode. The detection pattern remains active for the next 30 days, because the PoC is public and mass-exploit waves typically arrive a week after patch disclosure.

What we did not do: restart the NGINX service on all hosts at the same time. The service reload (systemctl reload nginx) finishes open connections cleanly while the patch is already active in the new workers. A restart would have severed open tenant connections, which during business hours on a live-traffic tenant platform produces a visible service dip.

The structural lesson from this episode does not sit in the heap overflow, but in the relationship between the sizing path and the write path in an old codebase. NGINX has worked stably for 18 years because the discrepancy between ngx_escape_uri() and ngx_escape_html() in the special-character set never became sharp through a typical configuration class. The lesson lies in configuration discipline. Named captures are not a pure code-style question; they are a robustness discipline against precisely this class of findings that arise from internal-function inconsistencies. That is the structural class in which the web-server layer currently stands: not compromised by malicious traffic, but by old consistency assumptions that break in rare configuration paths. In the current May week we have seen exactly this pattern in Apache mod_http2 (CVE-2026-23918 from 13 May) and now in NGINX Rift — both HTTP-server classes sit in the same structural weakness.

In the broader architecture arc the answer is not a single patch but web-server configuration discipline as its own platform component. Patching to the fixed line is the emergency measure. The structural answer is a curated NGINX configuration template with named captures as the default, a pre-receive hook against unnamed captures in the central configuration repo, and a quarterly configuration audit on comparable consistency paths. Three disciplines that would not individually have prevented NGINX Rift, but together reduce the impact surface of a comparable incident to a few configuration paths rather than 23 hosts.

Conclusion

CVE-2026-42945 is, in the May patch cycle, a structural flaw of the most serious class: CVSS 9.2, unauthenticated, internet-facing, 18 years old, present in mainline and NGINX Plus in parallel, with a public PoC since 14 May. What makes the finding operationally tolerable is the rapid patch availability (13 May from 07:00 UTC) and the clear trigger condition (unnamed capture + question mark + follow-up directive), which can be addressed at the configuration layer.

The question is not whether nginx 1.30.1 is enough. The patch line is enough for the concrete path NGINX closed on 13 May. The question is whether your platform runs web-server configuration discipline as its own component, or whether NGINX configurations continue to drift through tenant maintenance as a “platform detail”. The structural answer is the first option: curated configuration templates, named captures by default, a pre-receive hook against the fragile pattern, a quarterly configuration audit on comparable consistency paths.

Personal background and technical detail on web-server discipline in the German Mittelstand: ole-hartwig.eu.