On 14 May 2026 security researchers at depthfirst and F5 disclosed one of the most consequential web-server vulnerabilities of the year so far: a critical, unauthenticated remote-code-execution flaw in the NGINX ngx_http_rewrite_module that has sat undetected in production for 18 years. Tracked as CVE-2026-42945 and codenamed NGINX Rift, it carries a CVSS v4 base score of 9.2 and is reachable by a single crafted HTTP request — no authentication, no prior access, no existing session, no user interaction.

The disclosure also brings three additional unauthenticated NGINX flaws to light at the same time, and lands the same week as Microsoft’s 138-CVE May Patch Tuesday and an Ivanti EPMM zero-day already on the CISA KEV list. For UK SMEs — the overwhelming majority of which run NGINX somewhere in the stack, whether they realise it or not — this is not an exotic concern. It is a 14-day Network Admin remediation window with audit, patch, configuration-review and Cyber Essentials v3.3 implications all bundled together.

9.2

CVSS v4 of CVE-2026-42945 (NGINX Rift)

18 yrs

The flaw sat undetected in production since 2008

New unauthenticated NGINX CVEs released on 14 May 2026

14 days

Cyber Essentials v3.3 patch window for ‘critical’ CVEs

What was actually announced

F5 published an advisory (K000161019) and depthfirst published the technical write-up — NGINX Rift — on 14 May 2026 following a responsible-disclosure window that opened on 21 April. Four CVEs were addressed together:

CVE-2026-42945 (CVSS v4 9.2) – the headline issue. A heap buffer overflow in ngx_http_rewrite_module. Triggers when the rewrite directive is followed by a rewrite, if or set directive and an unnamed Perl-Compatible Regular Expression capture (for example $1, $2) where the replacement string includes a question mark. A remote attacker can send a single crafted URI and corrupt the worker-process heap. With Address Space Layout Randomisation (ASLR) disabled, the corruption is reliably weaponisable into full remote code execution.
CVE-2026-42946 (CVSS v4 8.3) – an excessive-memory-allocation flaw in ngx_http_scgi_module and ngx_http_uwsgi_module that lets an attacker positioned as an adversary-in-the-middle force the worker process to read out-of-bounds memory or restart.
CVE-2026-40701 (CVSS v4 6.3) – a use-after-free in ngx_http_ssl_module reachable when ssl_verify_client is set to on or optional and ssl_ocsp is enabled.
CVE-2026-42934 (CVSS v4 6.3) – an out-of-bounds read in ngx_http_charset_module that can disclose memory contents.

Fixed versions are NGINX Open Source 1.30.1 and 1.31.0 (mainline). For NGINX Plus the fixes land in R32 P6 and R36 P4. The affected product surface is broad: NGINX Plus R32–R36, NGINX Open Source 1.0.0–1.30.0, NGINX Instance Manager 2.16.0–2.21.1, NGINX App Protect WAF 4.x and 5.x, F5 WAF for NGINX, F5 DoS for NGINX, NGINX Gateway Fabric 1.x and 2.x, and NGINX Ingress Controller 3.x, 4.x and 5.x. NGINX Open Source 0.6.27–0.9.7 will not receive a fix — those versions are well past end-of-life and any deployment still running them should be considered out of scope and replaced.

If you cannot patch immediately, the recommended mitigation for CVE-2026-42945 is a configuration change: replace every unnamed PCRE capture in every rewrite directive with a named capture. This requires a careful audit of nginx.conf, every conf.d/*.conf, every sites-available/* file and every per-vhost include. It is a real piece of work; treat it as a 24-to-48-hour exercise across an SME estate.

Why this matters in plain English

NGINX powers the front of nearly every modern UK SME website — either directly or as the reverse proxy in front of WordPress, WooCommerce, Laravel, Django, Node.js, container ingress controllers and managed CDN edges. A single crafted HTTP request to a vulnerable instance can let an attacker run code on your web server. From there, every secret in your application environment — database credentials, Stripe keys, Microsoft 365 service-principal secrets, GitHub deploy keys — is in scope. This is the most reachable web-server flaw to hit the UK SME estate since Log4Shell.

How we got here: the 5-week NGINX Rift timeline

21 April 2026 — Coordinated disclosure

depthfirst privately reports CVE-2026-42945 to F5. The buffer-overflow primitive is confirmed reproducible against NGINX Open Source builds shipped continuously since 2008.

28 April 2026 — Internal patch development

F5 confirms the affected product matrix internally. Patches drafted for NGINX Plus R32 and R36 and for NGINX Open Source 1.30.x and 1.31.x mainline.

5 May 2026 — ASLR conditions documented

depthfirst confirms reliable code execution on systems with ASLR disabled. Many container images and minimal Linux distributions ship with relaxed ASLR settings, expanding the realistic exploit population.

13 May 2026 — Coordinated release frozen

F5 freezes the May patch bundle covering CVE-2026-42945, CVE-2026-42946, CVE-2026-40701 and CVE-2026-42934. Notice is issued to the NGINX security mailing list under embargo.

14 May 2026 — Public disclosure

F5 advisory K000161019 and depthfirst’s NGINX Rift write-up published. NGINX Open Source 1.30.1 and 1.31.0 ship to the official repository. NGINX Plus R32 P6 and R36 P4 released to F5 customers.

15–21 May 2026 — Expected exploit weaponisation window

Past NGINX disclosures have produced functional proof-of-concept exploits within 7–10 days. Mass internet scanning for vulnerable HTTP responses typically begins inside 72 hours of disclosure.

28 May 2026 — Cyber Essentials v3.3 14-day patch deadline

Any UK organisation holding (or applying for) Cyber Essentials under the new v3.3 Danzell question set must have a critical-severity CVE remediated within 14 days of vendor patch availability. For NGINX Rift, that clock started ticking yesterday.

Where NGINX hides in a typical UK SME stack

The most common reaction to a flagship NGINX advisory is “we don’t run NGINX”. In our experience, that is almost never true. NGINX has spent the last decade quietly becoming the default web-server layer across the SaaS, PaaS and managed-hosting ecosystem, and most UK SME businesses run it multiple times in their estate without ever provisioning it deliberately. The chart below shows where we tend to find it during our Network Admin audits.

WordPress / WooCommerce (managed host front-end)

91%

Reverse proxy in front of an internal app

78%

Kubernetes / container ingress controller

64%

Magento, Laravel or Node.js app server bundle

58%

Cloud LB sidecar / app gateway component

42%

F5 NGINX Plus subscription on bare metal

31%

Edge appliance / WAF in front of HQ services

24%

The headline figure: in 91% of the SME audits we completed in Q1 2026, NGINX was running on a managed-hosting front end — usually invisibly, packaged inside a one-click WordPress or WooCommerce deployment. The customer never installed NGINX themselves and is almost never on the version-update mailing list. The patching responsibility quietly belongs to whoever owns the configuration — not to the host.

The unguarded attack surface: how exposed are UK SMEs today?

Of UK SMEs cannot answer the question “which NGINX versions are currently running on your estate, including all reverse proxies and ingress controllers?” within one working day

Until you can answer that question quickly — and with evidence — CVE-2026-42945 is unmanageable, not because patching is hard but because you do not know what to patch. The 75% gap is the single most important metric in this article. Everything below assumes you intend to close it inside the 14-day Cyber Essentials window.

The exposure map: where vulnerable UK SMEs are losing today

Common NGINX Rift exposure factors we see in the field

Production NGINX still on 1.18.x, 1.20.x or 1.22.x (no upgrade path scheduled) High

Rewrite directives using unnamed PCRE captures ($1, $2) and a question mark High

Container images built on top of nginx:latest or nginx:alpine from before today High

Kubernetes ingress controllers (3.5+, 4.x, 5.x) without an autoupdate channel High

NGINX Gateway Fabric 1.x or 2.x with no patching SLA in place Mid

Managed WordPress / WooCommerce host where the hosting contract is silent on edge patching Mid

ASLR disabled at the kernel level (older container hosts, minimal Linux images) High

No automated configuration-change audit trail for nginx.conf Mid

The realistic cost of getting this wrong

For UK SMEs the “cost of a breach” conversation is usually too abstract. NGINX Rift is unusually concrete because the realistic worst case is well understood: a web-server takeover, theft of credentials in environment variables, lateral movement into Microsoft 365 tenants or AWS / Azure cloud accounts, then either ransomware deployment or quiet data exfiltration ahead of a Stage 2 extortion demand. The numbers below are a band-by-band synthesis from the 2025/2026 Cyber Security Breaches Survey and our own incident response work for UK SMEs in the last 12 months.

UK SME band	Indicative breach cost	Realistic downtime	Cyber-insurance loading after a missed-patch claim
1–9 staff	£7,200 – £14,500	1–3 working days	+15–20%
10–49 staff	£18,400 – £46,000	3–6 working days	+18–28%
50–249 staff	£58,000 – £220,000	5–12 working days	+25–35%
250+ staff	£250,000 – £1.6m	1–4 weeks (partial)	+30–45%, plus declination risk

The cyber-insurance column matters more than businesses usually expect. Under the 2025/2026 underwriting cycle every UK SME insurer we deal with asks the same question on renewal: “Have you applied vendor security patches rated critical to internet-facing systems within 14 days of release?” If you cannot evidence a yes for CVE-2026-42945, your renewal premium and excess move materially, and in the worst case the policy is declined outright.

Drift vs control: the Network Admin posture comparison

The drift posture (most UK SMEs today)

What gets in the way

Nobody owns the question “which NGINX versions do we run?”
Patches are applied by whichever developer happens to notice the advisory
Configuration changes happen by SSH, with no audit trail
No standing inventory of internet-facing services
Managed-hosting contracts are silent on critical-CVE patching SLAs
ASLR and other kernel hardening flags are accepted as “whatever the image ships with”
Cyber Essentials renewal is a paperwork exercise once a year
When a CVE lands, the response is “we’ll get to it”

The controlled posture (Cloudswitched Network Admin)

Where we take you

Single authoritative inventory of every NGINX instance — production, staging, edge, ingress, sidecar
Critical CVEs trigger a 14-day patch SLA tracked in a shared dashboard
Configuration-as-code: every nginx.conf in git, every change reviewed
Continuous external attack-surface scan with email alerting on vulnerable banners
Patch-evidence pack ready for cyber-insurance renewal and Cyber Essentials assessor
Hardened base images with ASLR, restricted modules, and no default-on rewrite footguns
Tabletop incident playbook rehearsed quarterly
Same-day mobilisation when a critical CVE drops

The 10-step 14-day NGINX Rift Network Admin response programme

If you take only one operational message away from this article, take this one: NGINX Rift is not a 24-hour fire-drill, it is a 14-day controlled-remediation programme. Below is the exact sequence we run for our Network Admin clients when a CVE of this severity lands. Each step has an owner, an output and a place to file the evidence.

Step 1 — Build an authoritative NGINX inventory across the whole estate

Day 1

Step 2 — Run an external scan for vulnerable Server banners and version strings

Day 1–2

Step 3 — Audit every nginx.conf for unnamed PCRE captures plus question-mark replacements

Day 2–3

Step 4 — Apply the patch (1.30.1 / 1.31.0 / R32 P6 / R36 P4) in staging, smoke-test

Day 3–5

Step 5 — Roll patched packages and container images into production behind a change ticket

Day 5–8

Step 6 — Confirm Kubernetes ingress controllers are on a fixed minor version, lock the chart

Day 7–9

Step 7 — Verify ASLR is enabled on every host running NGINX and document the result

Day 8–10

Step 8 — Refresh the patch-evidence pack for Cyber Essentials v3.3 and cyber insurance

Day 9–11

Step 9 — Add an automated nightly NGINX version-drift check to your monitoring

Day 10–13

Step 10 — Run a one-hour board-level briefing: what we did, what it cost, what is still open

Day 14

29/100

Median UK SME Network Admin readiness score for a critical web-server CVE in 2026

An average score of 29 out of 100 is unsentimental but accurate. The good news is that the gap is closeable inside the 14-day window if a programme exists; the bad news is that for most UK SMEs that programme does not yet exist on paper, so the first response to a critical CVE is improvisation rather than execution.

Quick win for the next 48 hours

Before any patching: run curl -I against every public website, application gateway and ingress hostname you own. Capture the Server header. If it returns nginx/1.18.x, 1.20.x, 1.22.x, 1.24.x, 1.26.x or 1.28.x — or anything older — you have at least one vulnerable production NGINX. Save the output, date-stamp it, and that becomes the first page of your patch-evidence pack. This single step takes 20 minutes and is worth more at insurance-renewal time than any number of tooling subscriptions.

Cross-reference with the wider 2026 UK SME threat landscape

NGINX Rift does not land in isolation. It joins a 30-day list of unauthenticated, internet-reachable flaws that have hit UK SME infrastructure. If you are running a serious Network Admin function, these are the parallel programmes that need to be tracked alongside it:

The 11 May WordPress mass-takeover wave (CVE-2026-5722 plus CVE-2025-13618, both CVSS 9.8) — same threat model: unauthenticated admin takeover of UK SME web stacks.
The Palo Alto PAN-OS zero-day currently under active exploitation across UK perimeter networks.
The 12 May Microsoft 365 Copilot Anthropic default — nothing to do with NGINX, but the same Cyber Essentials v3.3 evidence pack covers both.
The Veeam Data Resilience findings — if Step 5 of the plan above goes wrong in production, immutable cloud backup is what gets you back online.
The 26 June Secure Boot certificate cliff — a parallel deadline that should be folded into the same patching programme.
The NCSC patch-wave warning — the broader policy backdrop to all of the above.
The UK Cyber Resilience Pledge + £90m SME fund — where the long-term funding picture is going.

At-a-glance reference table for the next 14 days

What	Detail
Headline CVE	CVE-2026-42945 (NGINX Rift), CVSS v4 9.2
Component	`ngx_http_rewrite_module`
Class	Heap buffer overflow; unauthenticated remote code execution
Discovered by	depthfirst (responsibly disclosed 21 April 2026)
Public disclosure	14 May 2026
Fixed in (OSS)	NGINX Open Source 1.30.1 and 1.31.0
Fixed in (NGINX Plus)	NGINX Plus R32 P6 and R36 P4
Workaround	Replace unnamed PCRE captures with named captures in every rewrite directive
Other CVEs in the bundle	CVE-2026-42946 (8.3), CVE-2026-40701 (6.3), CVE-2026-42934 (6.3)
Affected ingress controllers	NGINX Ingress Controller 3.5.0–3.7.2, 4.0.0–4.0.1, 5.0.0–5.4.1
Affected gateway products	NGINX Gateway Fabric 1.3.0–1.6.2, 2.0.0–2.5.1
End-of-life branches with no fix	NGINX Open Source 0.6.27–0.9.7 (replace, do not patch)
Cyber Essentials v3.3 patch window	14 days from vendor patch availability — deadline 28 May 2026
F5 advisory	K000161019

Move from drift to control in 14 days

Cloudswitched Network Admin runs the NGINX Rift remediation programme above as a standing service for UK SMEs. Inventory, scan, patch, evidence pack, board briefing — in one engagement, with a fixed scope and a fixed timeline. Critical CVE response stops being an improvisation.

Talk to us about Network Admin Services

Frequently asked questions

We use Cloudflare in front of our website. Doesn’t that protect us from NGINX Rift?

Cloudflare and other reverse-proxy CDNs sit in front of your origin. They reduce the population of attackers who can reach your NGINX directly but they do not eliminate it — the origin is still reachable via direct IP, Origin Pull, and many real-world misconfigurations. More importantly, the rewrite directive runs on your NGINX, not on Cloudflare. A crafted URI passed through Cloudflare to your origin still triggers the vulnerability. Treat Cloudflare as defence-in-depth, not as a patch substitute.

We use a managed-hosting provider. They patch NGINX, right?

Sometimes. The managed-hosting market is fragmented and the patching SLA is not standard. Some hosts roll critical CVEs the same day they drop. Some treat NGINX as “customer responsibility” because it’s part of a customer-installed stack. Some make it impossible for you to tell which version you are on. The correct posture is to ask in writing — today — what your host’s 14-day patch SLA is, get a current version string, and file both as evidence. If the answer is unclear, that is itself a finding.

We don’t use the rewrite directive on our website. Are we safe?

Almost certainly no. The rewrite directive ships in almost every off-the-shelf NGINX configuration: WordPress permalinks, WooCommerce checkout, multi-domain SSL redirects, www-to-apex redirects, mobile-version routing and any HTTPS-enforcement block. Even minimal configurations usually include at least one rewrite. The trigger is the combination of a rewrite directive plus an unnamed PCRE capture plus a question mark in the replacement string — not the rewrite directive in isolation — but you cannot rule it out by inspection alone for a typical SME estate. Patch first, audit second.

We’re running NGINX inside a container image. Does the patch reach us automatically?

Only if you rebuild the image. Pulling the same tag again from your registry will not pick up the new base layer unless you explicitly re-pull or re-pin nginx:1.30.1 or nginx:1.31.0. The most common operational error in the next two weeks will be teams assuming a container restart fixed the issue when in fact the container is still running 1.28.0. Build the image, push it, redeploy, then re-scan.

We run Kubernetes with the NGINX Ingress Controller. What do we do?

Upgrade to a fixed minor version of the controller — the affected ranges are 3.5.0–3.7.2, 4.0.0–4.0.1 and 5.0.0–5.4.1. In practice that means bumping the Helm chart, doing a rolling restart of the controller pods, and confirming the new image hash is live across every node. Do not assume Helm autoupdates run on their own — in most SME clusters they don’t. Schedule the upgrade as a planned change with a clear backout step.

Is the workaround actually safe to deploy without the patch?

Yes, but only if it is applied consistently. The recommended mitigation — replacing every unnamed PCRE capture in every rewrite directive with a named capture — is reliable when it is applied across the entire configuration tree, including every include file. The risk is the missed include: if even one rewrite block still uses $1 with a question-mark replacement, the host remains exploitable. Treat the workaround as a stopgap that requires a verifying scan, not as a permanent fix.

How does NGINX Rift interact with Cyber Essentials v3.3?

Directly. The Danzell question set, live since 27 April 2026, requires evidence that critical vendor patches are applied within 14 days of release on internet-facing systems. CVE-2026-42945 is a critical, internet-facing, vendor-released patch — therefore the 28 May 2026 deadline applies to every UK organisation either holding or applying for Cyber Essentials. Assessor-acceptable evidence is a patched version string captured on or before 28 May, plus a date-stamped record showing when the change was made.

If we get hit before we patch, will our cyber insurance pay?

It depends on the policy wording, but the trajectory across the UK SME insurance market in 2025 and 2026 has been clear: critical CVE patching is now a near-universal policy condition, and the “14-day vendor patch” threshold is the most common formulation. If you suffer a NGINX-Rift-style compromise after 28 May 2026 and cannot evidence the patch was applied, expect a partial or full claim refusal, plus reputational consequences at next renewal. Don’t test it.

Should we replace NGINX with something else after this?

No. NGINX is a solid, well-engineered web server with an excellent disclosure cadence; an 18-year-old buffer overflow in one optional module does not change that. The right response is operational, not architectural: own the inventory, patch within the SLA, harden the base image, and track CVEs continuously. The wrong response is to start a multi-quarter web-server migration project that produces no security wins inside the 14-day window that actually matters right now.

How does Cloudswitched run this for clients?

Our Network Admin engagement runs the 10-step programme described above as a single piece of work, finishing inside 14 days with a board briefing and an evidence pack signed off for Cyber Essentials and cyber insurance. The recurring service then keeps NGINX (and the wider infrastructure estate) inside SLA continuously, with monthly vulnerability-management reports, quarterly tabletop exercises and same-day mobilisation when a critical CVE drops.

One critical CVE every two weeks is now the baseline

NGINX Rift is the headline this week. Two weeks from now it will be something else. Cloudswitched Network Admin makes the response routine instead of dramatic — inventoried, patched, documented and rehearsed, every time. Talk to us about a fixed-scope 14-day starter engagement.

Book a Network Admin discovery call

Tags:Network AdminCyber SecurityIT Support

CloudSwitched

London-based managed IT services provider offering support, cloud solutions and cybersecurity for SMEs.