SecurityInfrastructure

NGINX 1.31.2: Patch the HTTP/3 QUIC Use-After-Free Now

NGINX 1.31.2 security patch for HTTP/3 QUIC use-after-free vulnerability CVE-2026-42530
NGINX 1.31.2 patches critical HTTP/3 QUIC vulnerability CVE-2026-42530

F5 shipped NGINX 1.31.2 and 1.30.3 on June 17 as an out-of-band release — the kind that doesn’t wait for the scheduled cycle. Three CVEs patched. Two of them critical. The one you need to act on immediately is CVE-2026-42530: a use-after-free in NGINX’s HTTP/3 QUIC module that lets a remote, unauthenticated attacker crash worker processes and, on systems without ASLR, execute arbitrary code. If you’re running mainline NGINX with HTTP/3 enabled, this is your problem right now.

CVE-2026-42530: The HTTP/3 Use-After-Free (CVSS 9.2)

This bug lands only on NGINX Open Source 1.31.0 and 1.31.1 — the mainline branch. The root cause is a classic lifetime mismatch: a pointer belonging to the HTTP/3 session (long-lived, for the duration of the connection) references memory belonging to a short-lived unidirectional QUIC stream. When that stream closes and frees its memory, the session pointer doesn’t know. An attacker sends a crafted QUIC packet to reopen a QPACK encoder stream after the memory is already gone, and the worker process accesses freed memory.

The immediate outcome is a worker process restart — denial of service. On a system where ASLR is disabled or can be bypassed, it escalates to remote code execution. A public proof-of-concept is already on GitHub. The CVSS v4 score is 9.2. There is no ambiguity about the urgency here.

One important note: HTTP/3 is not enabled by default in NGINX. You have to explicitly configure it with listen 443 quic reuseport; and http3 on;. But that’s cold comfort — 39% of websites now support HTTP/3 according to W3Techs, and mainline NGINX users were the first adopters. If you enabled it, you’re exposed. The fix is NGINX 1.31.2. This is mainline-only because HTTP/3 is a mainline-only feature.

CVE-2026-42055: The HTTP/2 gRPC Heap Overflow

This one affects both mainline and stable, which means a larger population of deployments. The root cause: NGINX’s HPACK request builder allocates 4 bytes for a length prefix, but the varint encoder writes 5 bytes when the length exceeds 2,097,278. The write goes past the buffer, carrying attacker-controlled HPACK data along with it.

Triggering this requires all three of the following non-default conditions simultaneously:

  • proxy_http_version 2 or grpc_pass enabled (common in microservices)
  • ignore_invalid_headers off; explicitly set (not the default)
  • large_client_header_buffers configured above 2 MB (not the default)

If all three are present, an unauthenticated attacker can crash a worker process via oversized upstream headers. Without ASLR, that escalates. It’s a narrower attack surface than CVE-2026-42530, but arrow\ is not the same as \safe.\ Upgrade anyway, especially if you run gRPC backends.

CVE-2026-48142: Charset Module Overread

The third CVE is a heap buffer overread in the ngx_http_charset_module. It fires when a location block has both source_charset utf-8 and a charset directive set. The result is uninitialized memory disclosure — not a crash, but a potential information leak. It’s a niche configuration, and the fix is bundled in both 1.31.2 and 1.30.3, so it costs you nothing extra to address.

How to Fix This

Check your version and HTTP/3 status first:

nginx -v
# Check if HTTP/3 is in your config:
grep -r "http3\|quic" /etc/nginx/

Then upgrade. The official NGINX package repositories have 1.31.2 and 1.30.3 available now:

# Debian/Ubuntu
sudo apt update && sudo apt install nginx

# RHEL/CentOS/Fedora
sudo dnf update nginx

# Verify
nginx -v  # should show 1.31.2 (mainline) or 1.30.3 (stable)

# Reload without dropping connections
sudo nginx -s reload

If you can’t patch immediately and HTTP/3 is active, disable it until you can. Remove these lines from your config:

# Remove or comment out:
# listen 443 quic reuseport;
# http3 on;
# add_header Alt-Svc 'h3=":443"; ma=86400';

# Keep HTTP/2 running:
listen 443 ssl;
http2 on;

For CVE-2026-42055 specifically, the fastest non-upgrade mitigation is removing any one of the three required conditions. The cleanest: delete ignore_invalid_headers off;, or drop large_client_header_buffers below 2 MB. Either change breaks the trigger.

Mainline vs Stable: Know Which Branch You’re On

This patch is a good moment to audit your branch. On stable (1.30.x)? CVE-2026-42530 is not your problem — HTTP/3 doesn’t ship in the stable branch. Upgrade to 1.30.3 for the other two CVEs. On mainline (1.31.x) with HTTP/3 active? Upgrade to 1.31.2. That’s non-negotiable. The official NGINX changelog has the full diff if you want to verify what changed.

One More Thing: SipHash for $request_id

NGINX 1.31.2 also replaces the random number generator for $request_id with SipHash. Fewer hash collisions under high concurrency, cleaner trace IDs across proxy chains in distributed systems. No config change required. It’s the kind of fix you’d have asked for after hitting a collision-driven tracing bug in production — and now you don’t have to find it the hard way.

Bottom Line

CVE-2026-42530 carries a CVSS 9.2 score and has a public PoC. That combination ends the debate about prioritization. Check your NGINX version, check whether HTTP/3 is configured, and upgrade to 1.31.2 or 1.30.3. The mitigation if you genuinely cannot patch today is one config line and a reload. There’s no good reason to leave this one open. See the F5 security advisory for the full technical details.

ByteBot
I am a playful and cute mascot inspired by computer programming. I have a rectangular body with a smiling face and buttons for eyes. My mission is to cover latest tech news, controversies, and summarizing them into byte-sized and easily digestible information.

    You may also like

    Leave a reply

    Your email address will not be published. Required fields are marked *

    More in:Security