Two critical nginx bugs: use-after-free in HTTP/3 and heap overflow in the gRPC proxy

Picture this: your nginx serves as an API gateway, proxying HTTP/2 traffic to a microservices backend. At some point you set ignore_invalid_headers off to pass through non-standard headers from one of your upstream services, and bumped large_client_header_buffers to 4 MB to handle large JWTs. Everything works, no complaints. Then on June 17, 2026, F5 drops an out-of-band security advisory — and it turns out that exact configuration lets an unauthenticated remote attacker crash your nginx worker processes with a single request. That’s just one of the two critical bugs patched that day.

F5 disclosed six vulnerabilities across the NGINX product ecosystem. Two of them are critical RCE-class issues, both scoring CVSS v4.0: 9.2. CVE-2026-42530 is a use-after-free in the ngx_http_v3_module, which handles HTTP/3 over QUIC. CVE-2026-42055 is a heap-based buffer overflow in the HTTP/2 proxy and gRPC pass modules. Both allow an unauthenticated remote attacker to crash nginx worker processes, and on systems where ASLR is disabled or can be bypassed — potentially execute arbitrary code. Both are fixed in nginx 1.31.2, released the same day.

No active exploitation has been confirmed at the time of publication. That won’t last: CVE-2026-42945 (NGINX Rift) went from public disclosure to active in-the-wild exploitation in under a week back in May 2026. A working proof-of-concept was reconstructed from the patch diff almost immediately. There’s no reason to expect these two will move slower.

HOW THE HTTP/3 BUG WORKS (CVE-2026-42530)

HTTP/3 runs over QUIC, which — unlike TCP — multiplexes data across several independent streams within a single connection. Header compression in HTTP/3 uses QPACK, a mechanism more complex than HTTP/2’s HPACK precisely because QUIC streams can arrive out of order. QPACK relies on two dedicated control streams: an encoder stream (the sender pushes compression table updates) and a decoder stream (the receiver acknowledges them). The protocol says each of these streams opens once per connection and stays open. Reopening is not allowed.

The bug in ngx_http_v3_module is in how nginx handles a client that tries to reopen the QPACK encoder stream inside an already-established HTTP/3 session. When the stream first opens, nginx allocates memory for its data structures. When it closes, that memory is freed. When the client reopens the stream, nginx doesn’t properly check that edge case — the worker process tries to access data structures that have already been freed. Classic use-after-free (CWE-416): reading or writing memory that’s been handed back to the allocator or reassigned to something else.

Only NGINX Open Source 1.31.0 and 1.31.1 are affected — the versions where HTTP/3 support was introduced or significantly reworked. The 1.30.x branch is clean. CWE-416 is documented in the F5 advisory under internal ID NPS-8. The bug was found by Trung Nguyen (@everping) of CyStack, credited in the official nginx changelog. F5’s advisory K000161616 additionally credits Zhenpeng (Leo) Lin (depthfirst), Evan Hellman (@xintenseapple) of Trail of Bits in collaboration with OpenAI, and the teams at AntAISecurityLab and Nebula Security (@nebusecurity).

HOW THE HTTP/2 PROXY AND gRPC BUG WORKS (CVE-2026-42055)

This one needs three non-default configuration options set simultaneously. First: HTTP/2 proxying enabled via proxy_http_version 2 or a grpc_pass directive. Second: ignore_invalid_headers set to off. Third: large_client_header_buffers configured larger than 2 megabytes. With default nginx settings all three of these are non-issues — ignore_invalid_headers defaults to on, and large_client_header_buffers defaults to 4 buffers of 8 KB each.

Setting ignore_invalid_headers off tells nginx to stop filtering headers with malformed names at the ingress point and pass them through — including when building upstream requests. The ngx_http_proxy_v2_module and ngx_http_grpc_module modules build upstream request headers by copying data into a heap buffer. The size of that buffer is calculated under the assumption that the headers have already been validated. When large_client_header_buffers exceeds 2 MB and validation is off, an attacker can send headers large enough to push the copy operation past the end of the allocated buffer. Heap-based buffer overflow (CWE-122): the overflow corrupts adjacent allocator metadata or live objects on the heap.

The bug was found by Mufeed VH of Winfunc Research, credited in the official nginx.org changelog for version 1.31.2. Affected versions span nginx 1.13.10 through 1.31.1 — nearly a decade of releases. The fix landed in NGINX Open Source 1.31.2 (mainline) and 1.30.3 (stable), and in NGINX Plus 37.0.2.1 and R36 P6 for commercial deployments.

HOW EXPLOITATION WORKS

For CVE-2026-42530 (HTTP/3 UAF): the attacker opens an HTTP/3 connection to the server over UDP/443. No authentication required — a QUIC connection is publicly accessible by design. Inside the session, the attacker opens the QPACK encoder stream, closes it, then opens it again — something the protocol explicitly prohibits, but nginx 1.31.0–1.31.1 doesn’t enforce correctly. The worker process tries to access already-freed data structures and crashes with memory corruption. nginx automatically restarts crashed workers, so the service recovers — but keep sending that session and the DoS loops indefinitely.

For CVE-2026-42055 (HTTP/2/gRPC heap overflow): the attacker sends an HTTP request carrying intentionally oversized or malformed headers — large enough to overflow the calculated buffer when they’re copied into the upstream request structures. Header filtering is off thanks to ignore_invalid_headers off, so the headers go straight into the proxy module’s heap buffer. Same result: worker crash, DoS.

Worth noting: F5’s advisory uses the phrase “conditions beyond their control” when describing CVE-2026-42055. That’s intentional wording — it acknowledges that the attacker can’t control all the preconditions unilaterally. The server has to be configured in a specific non-default way. That’s exactly why the bug requires three directives in combination — it’s not “send a big header,” it’s “send a big header to a server that deliberately disabled validation and enlarged its buffers.” But from the attacker’s perspective: if the configuration matches, there are no technical barriers left. One HTTP request with bloated headers is all it takes.

WHAT HAPPENS NEXT — DEPENDS ON YOUR SETUP

On systems with ASLR enabled — the default on all modern Linux distributions — both bugs reliably produce DoS: worker crash and restart. ASLR randomizes memory addresses on each run, which makes predicting where to redirect execution after a corruption substantially harder. It’s not a defense against the crash itself, but against RCE it’s a significant — if not absolute — barrier.

On systems where ASLR is disabled or can be bypassed — and a public video demonstration of CVE-2026-42530 already exists, with researchers confirming that ASLR bypass is realistic — memory corruption becomes a controllable primitive. The heap overflow from CVE-2026-42055 corrupts adjacent allocator metadata or live heap objects, which is the standard launchpad for control-flow hijacking according to independent security researchers. The use-after-free from CVE-2026-42530 gives a read/write primitive into freed memory — the same raw material. F5 states it explicitly in both advisories: on systems where ASLR is disabled or bypassed, arbitrary code execution is possible.

One more detail from the official nginx.org changelog: CVE-2026-48142, a buffer overread in ngx_http_charset_module patched in the same 1.31.2 release, is officially described as enabling “limited disclosure of worker process memory.” Researchers at thecybersecguru.com note that this kind of memory leak is precisely the tool an attacker would use to defeat ASLR before triggering CVE-2026-42530 or CVE-2026-42055. That’s their assessment, not an official F5 claim. All three CVEs are closed by a single update to 1.31.2.

TIMELINE

June 17, 2026 — F5 publishes out-of-band security advisory K000161614 covering six CVEs across the NGINX product ecosystem. nginx 1.31.2 (mainline) and 1.30.3 (stable) are released simultaneously with the patches. “Out-of-band” is the key detail here: F5 normally follows a quarterly security notification schedule. Breaking from that cycle means the wait wasn’t acceptable.

June 19, 2026 — SecurityLab and Xakep.ru publish coverage. The nginx.org security advisories page is updated with six new entries. At the time of publication, no active exploitation of CVE-2026-42530 or CVE-2026-42055 has been confirmed and no public PoC has been released. According to SOCRadar, researchers are tracking CVE-2026-42530 under the unofficial name nginx-quicburst, and a public video demonstration of the bug already exists — a signal that technical understanding of the vulnerability has spread well beyond the original research group.

WHY THIS MATTERS

Both bugs are network-exploitable, unauthenticated, and require zero user interaction. That’s the most attacker-friendly combination possible: all they need is IP-level access to your nginx on port 443. No password to guess, no CMS vulnerability to chain, no waiting for someone to click a link. One UDP packet and the worker is down.

The CVSS confusion here is real and worth understanding. CVE-2026-42530 and CVE-2026-42055 have three different scores depending on the source: CVSS v3.1 — 8.1 High (per CSA Singapore and Tenable), CVSS v4.0 — 9.2 Critical (per the F5 advisory), and nginx.org’s internal severity labels — “major” and “medium” respectively. All three are correct — they’re just measuring different things. CVSS v4 recalibrated how it scores network-exploitable memory corruption bugs and tends to push them higher than v3.1 did for the same underlying flaw. nginx.org’s internal labels reflect the project team’s own read on exploitation reliability, which has historically been more conservative. If your vulnerability management tooling pulls from a single CVSS feed, you might see “medium” and “critical” for the same bug from different legitimate sources. Go with CVSS v4.0: 9.2 — it’s the more current framework.

CVE-2026-42055 covers nginx 1.13.10 through 1.31.1. That’s close to a decade of releases under one vulnerable code path — conditional on the right configuration being in place. “Non-default configuration” doesn’t mean exotic: HTTP/2 proxying with relaxed header handling and enlarged buffers is exactly what people set up when serving gRPC traffic, large JWTs, and non-standard API schemes. Production microservices infrastructure.

UPDATE

Check your current nginx version first — it’ll tell you which branch you’re on and whether you need to act:

nginx -v

If the output shows 1.31.0 or 1.31.1, you’re exposed to both CVE-2026-42530 and CVE-2026-42055. Any version from 1.13.10 through 1.31.1 means CVE-2026-42055. Update to 1.31.2 (mainline) or 1.30.3 (stable). On Ubuntu/Debian, if nginx is installed from the official nginx.org repository, this will update it to the latest available version:

apt update && apt install nginx

If nginx came from the distribution’s own repository — Ubuntu universe, for example — you may be on an older build that hasn’t received the patch. Check where the package came from with apt-cache policy nginx. If the output shows an address like nginx.org/packages, you’re fine. If it shows a distribution URL, check the version and switch to the official nginx.org repository if needed.

On RHEL/CentOS/AlmaLinux, use dnf — this updates nginx to the latest version available in your configured repositories:

dnf update nginx

After updating, confirm the new version is running — the output should show 1.31.2 or 1.30.3:

nginx -v && systemctl status nginx

If you can’t patch immediately, use temporary workarounds — they reduce your exposure but don’t replace the patch. Update as soon as possible. For CVE-2026-42530: disable HTTP/3 by removing the quic parameter from all listen directives. This eliminates the attack surface entirely since the vulnerability is unreachable without HTTP/3. Verify nothing with quic remains in your config — the command prints every line where the word appears:

grep -r "quic" /etc/nginx/

If the output includes lines like listen 443 quic reuseport; or http3 on;, comment out or remove exactly those lines and reload nginx. Empty output means HTTP/3 isn’t enabled and CVE-2026-42530 doesn’t apply to you.

For CVE-2026-42055: either restore ignore_invalid_headers to its default value of on, or drop large_client_header_buffers below 2 MB. Either change alone is enough — the bug requires both conditions at once. Check whether the relevant directives are in your config:

grep -r "ignore_invalid_headers\|large_client_header_buffers" /etc/nginx/

No output means you’re running defaults and CVE-2026-42055 doesn’t apply. If you see output, look at the values: ignore_invalid_headers off combined with large_client_header_buffers above 2 MB is the vulnerable combination. After any configuration change, test and reload:

nginx -t && systemctl reload nginx

CONCLUSIONS

Two critical nginx bugs in a single day is not routine, and F5 issuing an out-of-band advisory confirms that. CVE-2026-42530 affects a narrow but growing segment — anyone running HTTP/3 on nginx 1.31.x. CVE-2026-42055 covers a massive version range — 1.13.10 through 1.31.1 — under a non-default but practically common configuration.

All three vulnerabilities — CVE-2026-42530, CVE-2026-42055, and CVE-2026-48142 — are fixed by a single update to 1.31.2. The patch exists, it’s stable, and it shipped the same day as the advisory. Update now. On Debian/Ubuntu: apt update && apt install nginx. On RHEL/AlmaLinux: dnf update nginx. NGINX Rift showed that the window between “patch released” and “exploit in the wild” is measured in days, not weeks.