NGINX is carrying a serious bug in its HTTP/3 support. The identifier is CVE-2026-42530, and it lives in ngx_http_v3_module, the module that implements QUIC. It’s a use-after-free: the code reaches back into memory it has already freed. When that happens inside a worker process serving connections from anyone on the internet, the problem stops being academic.
The trigger sits in the QPACK layer, the header-compression mechanism in HTTP/3. A remote client, with no authentication, can build a crafted HTTP/3 session that reopens a QPACK encoder stream that was already closed. That second use touches freed memory and the worker crashes. In the worst case, on a system without ASLR or with ASLR that can be bypassed, the attacker can turn the memory corruption into code execution running with the worker’s privileges.
Who is affected
Only NGINX Open Source 1.31.0 and 1.31.1 with HTTP/3 (QUIC) enabled are exposed. The 1.31 branch reworked that part of the code, and that’s where the bug slipped in. If your server doesn’t listen over HTTP/3 (no listen ... quic; directives and no http3 on;), the vulnerable module never runs and this CVE doesn’t apply to you. Earlier stable branches are not flagged in this advisory.
Severity
F5, which maintains NGINX, rates this as critical. The CVSS 4.0 score is 9.2, while the CVSS 3.1 calculation comes out at 8.1 (high). The gap reflects how each version of the scale weighs a network-facing, unauthenticated flaw with code-execution potential. The attack vector is the network, and it needs no credentials and no user interaction, though turning it into RCE depends on system conditions (mainly ASLR being unavailable). The likeliest outcome in practice is repeated worker crashes, meaning denial of service.
Mitigation
The fix landed in NGINX 1.31.2. Update to that release or later and restart the service. If you can’t patch right away, the most direct workaround is to disable HTTP/3 by removing the QUIC listeners from your configuration and keeping traffic on HTTP/2 and HTTP/1.1, neither of which uses the affected code. Keeping ASLR enabled on the host (the default on any modern distribution) lowers the chance that a bug like this escalates from a crash to code execution, but it’s no substitute for the patch.
If you run NGINX from your distribution’s packages, check your vendor’s security advisories: packaged builds usually carry the upstream branch number plus their own suffix, so confirm that the 1.31.2 change has been backported.
For context on other recent NGINX flaws, see our article on the man-in-the-middle injection when proxying to TLS servers (DSA-6131-1).