Critical nginx flaw CVE-2026-42945: check your version, patch and secure it

On 13 May 2026 the nginx project published a security advisory for CVE-2026-42945 – a heap buffer overflow in the ngx_http_rewrite_module with a CVSS v4.0 score of 9.2. The bug has been in the code since version 0.6.27 (2008); an unauthenticated attacker can crash the worker process with a single crafted HTTP request and, under specific conditions (ASLR disabled), execute code. Practically every nginx installation from 0.6.27 to 1.30.0 is affected. This article walks through the sober workflow: determine the version, compare it against the affected releases, patch, verify.

Who is affected – and what is fixed

According to the official nginx security advisory:

• Vulnerable: nginx 0.6.27 up to and including 1.30.0
• Not vulnerable: 1.30.1 (stable branch) and 1.31.0 (mainline branch) and newer

The flaw only triggers when your configuration uses a rewrite pattern with an unnamed PCRE capture ($1, $2 …) and a question mark in the replacement string. Such patterns are everyday in practice – for example when rewriting query strings or appending parameters. But do not even start relying on your configuration being "not affected": analysing a live configuration is error-prone, and at a CVSS score of 9.2, simply bumping to a fixed version is far more reliable than any exception check. So first check which version is actually running, and then patch regardless of whether you suspect the triggering pattern in your configuration or not.

Important for context: public proof-of-concept code exists, and the flaw is already being actively exploited. VulnCheck observed exploitation attempts against its canary systems from 16 May 2026 – just three days after the advisory and PoC went public. That only raises the urgency: with an unauthenticated overflow and no preconditions, every day counts.

Step 1: Determine the installed version

On the host:

nginx -v
# nginx version: nginx/1.30.0

Containers often run different versions than the host. Check every nginx container individually:

# list all running containers
docker ps --format '{{.Names}}\t{{.Image}}'

# query the version inside a specific container
docker exec <CONTAINER_NAME> nginx -v

nginx -v writes the version output to stderr, not stdout – so if you redirect it to a file, append 2>&1.

Step 2: Compare against the affected versions

The comparison is simple: everything up to 1.30.0 is affected. Only 1.30.1 / 1.31.0 and higher are clean.

+----------------------+---------------------+
| reported version     | verdict             |
+----------------------+---------------------+
| 0.6.27 ... 1.30.0    | AFFECTED -> patch   |
| 1.30.1 (stable)      | OK                  |
| 1.31.0 (mainline)    | OK                  |
| >= 1.31.1            | OK                  |
+----------------------+---------------------+

Step 3: Patch

Option A: Bump the Docker image to a fixed tag

The official nginx Docker images follow two lines: nginx:stable (stable branch) and nginx:mainline or nginx:latest (mainline). In production, pin to a concrete fixed version instead of a moving tag:

# before (vulnerable)
FROM nginx:1.30.0

# after (fixed, stable branch)
FROM nginx:1.30.1

In a Compose stack, analogously:

services:
  web:
    image: nginx:1.30.1
    restart: unless-stopped

Pull and roll out:

docker compose pull
docker compose up -d

Option B: Update the distro package

If you use the nginx from your distribution's package sources, update via the package manager. Depending on the distribution, the patch lands as a backport into the existing version number – so the "distro version" may still show 1.30.0 even though the fix is applied (see pitfall 2).

# Debian/Ubuntu
sudo apt update && sudo apt install --only-upgrade nginx
sudo systemctl restart nginx

# RHEL/Alma/Rocky
sudo dnf upgrade nginx
sudo systemctl restart nginx

Step 4: Verify

After rolling out, query the version again – on the host and in every container:

nginx -v
docker exec <CONTAINER_NAME> nginx -v
# expected: nginx/1.30.1 (or higher)

With a distro backport, where the version number stays the same, check the package changelog instead:

# Debian/Ubuntu: does the changelog mention the CVE?
zcat /usr/share/doc/nginx/changelog.Debian.gz | grep -i 42945

Finally: is the service running cleanly again and responding?

docker compose ps
curl -sI http://localhost/ | head -n 1
# HTTP/1.1 200 OK

Three common pitfalls

1. Do not forget embedded nginx. nginx is not only in your reverse proxy. Many images ship their own nginx – frontend containers, nginx:*-based base images, the nginx Ingress in a Kubernetes cluster, or appliance images. Genuinely walk through every container with docker ps and docker exec ... nginx -v, not just the obvious proxy.

2. nginx -v does not always show the patch level. Distributions often backport security fixes into the existing version number. A 1.30.0 from the Debian sources may already be patched, while the same 1.30.0 as an official upstream binary is vulnerable. For distro packages, rely on the changelog, not the version line alone.

3. Confusing stable and mainline. The Docker tags nginx:stable and nginx:mainline point to different branches. The fix is in both (1.30.1 and 1.31.0 respectively). In production, pin to an exact version and do not blindly pull latest – otherwise the tag drifts uncontrolled on the next release.

Where to go from here

Treat the update as what it is at CVSS 9.2: urgent. For the details, it is worth looking at the official advisory overview, the rewrite module documentation, and the nginx changelog page, where you can read the exact fix per release.