NGINX Rift: what to do on nginx and VMBitrix

CVE-2026-42945 is a heap overflow in nginx’s rewrite module (researchers call it NGINX Rift). Without logging in, and with a specific config, an attacker can crash worker processes; with ASLR off or bypassed, that can lead to code execution.

The bug dates to ~2008: nginx Open Source from about 0.6.27 through 1.30.0. It does not hit every nginx — only configs with a rewrite using unnamed captures (`$1`, `$2`) in a replacement that contains `?`, plus another rewrite / if / set in the same scope. Typical VMBitrix setups enable rewrite, so risk is higher than on a bare static box.

In May 2026 F5 and nginx shipped patches (stable 1.30.1, mainline 1.31.0+). 1C-Bitrix built bx-nginx 1.30.2 for VMBitrix (covers Rift and related May CVEs, including nginx-poolslip). A public exploit exists; researchers saw exploitation attempts. The CVE is not on CISA KEV yet — priority is still high: public PoC plus a common RU stack.

Related: Bitrix on the perimeter, PHP2Shell, does a CVE affect you.

Sites and APIs behind nginx Open Source / Plus below a safe build, if the config matches the dangerous rewrite pattern.

Especially VMBitrix: the official 1C-Bitrix VM with bundled nginx. Bitrix24 cloud and 1C-Bitrix’s own infra were patched separately — this checklist is for your on-prem / VPS / VMBitrix.

Update nginx outside VMBitrix (proxies, CDN origins, Docker images) separately — bx-nginx does not cover them.

Forgotten stands: new subdomains.

Vendor baseline (confirm with your distro / image):

• nginx Open Source → 1.30.1 (stable) or 1.31.0+ (mainline); later 1.31.1 and newer
• VMBitrix → bx-nginx package 1.30.2 or newer
• nginx Plus → branch hotfixes per the F5 advisory (not a blind `dnf update nginx`)
• Distro build (Debian/Ubuntu/RHEL) → OS backport if the banner still looks “old” but the changelog lists CVE-2026-42945

The Server header is an outside hint, not ground truth: some hosts strip it or return “nginx” with no version.

1. On the VM, update packages per 1C-Bitrix guidance (typically `dnf clean all && dnf update` — confirm bx-nginx ≥ 1.30.2 landed).

2. Check the version: `rpm -q bx-nginx` or your image’s equivalent. If missing — Bitrix repos / support ticket.

3. After update, restart nginx and confirm sites respond.

4. Staging and a second VMBitrix in the same account — patch those too.

Updating the Bitrix landing module / CMS core ≠ patching nginx. Different layers.

Upgrade the package or image to a safe build. Do not keep old Docker tags without checking the CVE.

Until you can patch — reduce exposure: remove dangerous rewrites with unnamed captures and `?` in the replacement (advisory stopgap, not a substitute).

Multiple vhosts / reverse proxies in front of Bitrix or WordPress — patch the nginx that terminates external traffic.

Do not run public PoCs on production. Outside stack view: Radar.

The question is not “does the CVE exist” but “do we expose nginx, and is a vulnerable (or suspiciously old) version / VMBitrix stack visible”.

• Add the root domain in signalfort and verify DNS
• Wait for host discovery and stack matching
• If nginx / Bitrix are visible and matched, you get a finding (first as a match)
• “Confirmed” only after a safe check on a paid plan — not the same as “we were breached”

Start: free check. Vertical: Bitrix on the perimeter.

• Do not assume “Bitrix admin update closed nginx too”
• Do not leave a second VMBitrix / old Docker unpatched
• Do not treat “not on KEV” as “safe to wait” when a public exploit exists
• Do not run public exploits against production

Confirm the package/image is a safe build; if Server is visible, that you are not advertising 1.30.0 or older without a backport.

Review logs for odd requests to rewrite-heavy URLs around disclosure dates; check nginx config integrity.

If you suspect compromise — isolate the host and follow IR. signalfort helps with exposure and matches; it does not replace on-server forensics.