Is your nginx exposed? How to check and harden it

Two critical nginx holes, CVE-2026-42530 and CVE-2026-42055, both rated 9.2, dropped in June 2026, and the coverage made it sound like every nginx on earth was on fire. It wasn't. Each one only bites a specific setup. The first needs HTTP/3 switched on. The second needs you proxying to an upstream over HTTP/2, or running gRPC, with a couple of non-default buffers tweaked. A plain nginx serving files or reverse-proxying over HTTP/1.1 was never in range. So the honest first move isn't panic-patching, it's checking whether you even run the vulnerable config. Here's how to tell in about a minute, the version that actually fixes it, and the short hardening list that turns the next nginx CVE into a shrug.

Are you actually exposed?

Start here, because the answer is usually no. Both bugs are real and both work without authentication, but each one needs a config you had to switch on yourself.

CVE-2026-42530 is a use-after-free in the HTTP/3 module (ngx_http_v3_module). It only fires when you’ve actually turned HTTP/3 on, with something like listen 443 quic and http3 on in a server block. HTTP/3 is off by default, and plenty of builds don’t even ship the module, so if you never went looking for QUIC you’re almost certainly clear.

CVE-2026-42055 is a heap overflow in the HTTP/2 proxy and gRPC paths (ngx_http_proxy_v2_module, ngx_http_grpc_module). It needs proxy_http_version 2 or a grpc_pass, and on top of that ignore_invalid_headers off with large_client_header_buffers set above 2 MB. That’s a narrow corner. Most reverse proxies talk HTTP/1.1 to their upstreams and never touch those knobs.

So the static site. The WordPress box in front of php-fpm. The plain HTTP/1.1 reverse proxy. None of them were ever in range. Don’t take my word for it, check your own box:

That prints the version. Then sweep the config for the risky directives:

No matches, no exposure to these two. Matches, patch today and keep reading.

Patch to the fixed version

Exposed or not, upgrade. The releases that carry the fix:

• NGINX Open Source: 1.31.2 on the mainline branch, or 1.30.3 on the 1.30 stable branch.
• NGINX Plus: R36 P6, or 37.0.2.1 on the 37.0 line.

Check what you’re on with nginx -v. The catch is that your distro’s package often trails upstream by weeks, so a plain apt upgrade may not have the fix yet. The clean route is the official nginx.org repository, which tracks releases within days. Once the new binary is in, reload without dropping a single connection:

nginx -t tests the config first, so a stray typo can’t take the site down on reload. Small habit, saved me more than once.

Harden so the next one is a shrug

Patching is the reactive half. Hardening is the half where the next critical CVE lands and you barely look up, because the feature it abuses was never enabled and your version was never stale. The short list that earns its keep:

• Watch the nginx security advisories and patch quickly. This is the one that genuinely matters. Everything below is depth.
• Kill the version banner with server_tokens off;. It stops nginx printing its exact version in headers and error pages, which is the first line a scanner reads.
• Enable only what you use. HTTP/3 is nice, but if you don’t need it, not building it in opts you straight out of a whole class of bug. Same logic for every module you’re tempted to add.
• Lock down TLS and keep the cert chain clean. Our SSL checker shows the protocol and the full chain for any host in one look, and TLS 1.2 vs 1.3 covers what to actually switch on.
• Send the security headers. HSTS, plus a content security policy that does more than default-src *. The HTTP headers checker grades what you’re serving and names the fix for each gap.
• Rate-limit the obvious with limit_req and a sane client_max_body_size, so the cheap abuse never reaches your app.

None of that is exotic, and most of it is a few lines in a file you already have. The nginx that shrugs off the next headline is the boring one: patched, HTTP/3 off unless it’s earning its keep, a tidy header set, nothing switched on that nobody uses. If you run more than the one box, the same server-hardening basics sit underneath nginx itself, and they age just as well.

Frequently asked questions