Nginx ships two security releases in nine days: seven CVEs and why you should patch now

Two advisories in the same fortnight

When a project as mature as Nginx puts out two security releases in nine days, it's worth looking up from whatever you're doing. That's exactly what happened in mid-May: first the big batch on the 13th (six CVEs at once) and, as a bonus, another patch on the 22nd with a seventh.

None of them is the end of the world on its own, but together they touch parts almost everyone runs: the rewrite module, the HTTP/2 proxy, HTTP/3 and the resolver. If you manage web servers — your own or your clients' — this one's for you.

In one sentence

There are seven vulnerabilities spread across two releases. The scariest is a buffer overflow in the rewrite module (the one half the internet uses to rewrite URLs), and the most talked-about is an HTTP/2 request injection when Nginx acts as a proxy. The rest are out-of-bounds reads, an address spoofing flaw in HTTP/3 and a use-after-free in OCSP requests.

The good news: it's fixed by updating the package and reloading. No machine reboot.

All seven, ordered by what you should look at first

These are the figures exactly as published in Nginx's own security advisory:

The two in the rewrite module (CVE-2026-42945 and CVE-2026-9256)

These are the ones you care about most, for a simple reason: almost nobody serves without rewrite. Redirects, clean URLs, forcing HTTPS, proxy rewrites... all of that goes through that module. A buffer overflow there is, worst case, the doorstep to code execution. The fact that they had to touch it again nine days later (CVE-2026-9256) tells you the area was hot.

The HTTP/2 injection (CVE-2026-42926)

The flashiest one, though with conditions: it only bites if you configure Nginx to proxy upstream over HTTP/2 (proxy_http_version 2) and you use proxy_set_body. In that scenario an attacker can slip in bytes the upstream reads as extra HTTP/2 headers or frames, tampering with the request that lands behind it. Its CVSS is 5.8 (medium), but "request smuggling" patterns always cause more trouble than their score suggests. If you don't run that combination, you're not affected; if you do, it's a priority.

The other four

• CVE-2026-42946 and CVE-2026-42934: out-of-bounds reads in scgi/uwsgi and in charset. Memory disclosure or a crashed worker. Most relevant if you gateway to Python/PHP apps over SCGI/uWSGI.
• CVE-2026-40460: address spoofing in HTTP/3. Only touches you if you have QUIC/HTTP/3 enabled (increasingly common; if you followed our HTTP/3 piece, give it a look).
• CVE-2026-40701: use-after-free in the resolver's OCSP requests. Shows up with OCSP stapling and dynamic resolution.

Who's affected

• Affected branches: mainline 1.29.x up to 1.30.0, and stable versions earlier than 1.30.1. If your nginx -v is older than those numbers, you're in the bag.
• Highest risk: any internet-facing Nginx, and especially those acting as a reverse proxy (which is basically the default use case today). Almost everyone has the rewrite module active.

What to do today

No fluff. Check your version and update to the right branch.

1. Check which version you have

nginx -v

• On the stable branch, the target is 1.30.2 or newer.
• On mainline, the target is 1.31.1 or newer.

2. Update and reload (no downtime)

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

# RHEL / AlmaLinux / Rocky
sudo dnf update nginx
sudo nginx -t && sudo systemctl reload nginx

That nginx -t before the reload isn't optional: it validates the config and stops a reload from taking the service down over a silly typo. The reload swaps in the new binary without dropping in-flight connections.

If you installed Nginx from the official nginx.org repository instead of your distro's, update from there (nginx.org/packages). Distributions sometimes backport the fix while keeping the version number: don't trust the number alone, check the package date or your distro's security changelog.

3. If you can't update right now

Temporary mitigations depending on what you have exposed:

• HTTP/2 as a proxy (CVE-2026-42926): if you don't need proxy_http_version 2 with proxy_set_body, drop the proxy to HTTP/1.1 while you patch.
• HTTP/3 (CVE-2026-40460): if you have QUIC enabled experimentally, you can turn it off temporarily (listen 443 quic;) until you update.

These are stopgaps to shrink the attack surface. They don't replace the patch.

What we did

As soon as the 13th's batch dropped we rolled it out across the internet-facing Nginx boxes we manage, prioritising the ones doing reverse proxy with complex rewrite rules. When the second patch landed on the 22nd with CVE-2026-9256 — the rewrite module again — we ran another pass instead of assuming the first one had us covered. That's the difference between "I updated it the other day" and "it's on the right version": the second one you confirm with nginx -v, not from memory.

The same old routine

With Nginx, just like with the kernel, the five moves are the same:

• nginx -v to know where you stand.
• apt/dnf update.
• nginx -t to validate.
• systemctl reload nginx.
• nginx -v again to confirm.

Keeping your update plan current isn't a luxury: it's what turns a batch of seven CVEs into an ordinary Tuesday rather than an incident. If your web server hasn't seen a patch in months, let's talk.

References

• nginx security advisories — nginx.org
• nginx news 2026 — nginx.org
• CVE-2026-42926 Detail — NVD
• NGINX ngx_http_rewrite_module vulnerability CVE-2026-42945 — oss-security