CVE-2026-42530: What the NGINX HTTP/3 PoC Proves—and What It Doesn’t

CVE-2026-42530 is real, serious, remotely reachable on exposed HTTP/3 services—and widely mislabeled online as a finished “NGINX RCE PoC.” The public evidence we verified demonstrates a QPACK-triggered use-after-free, worker crashes, and a scanner that can distinguish vulnerable from patched behavior. The original researcher also describes a controlled-write primitive. What we did not verify is a complete public ASLR bypass, stable end-to-end remote command-execution chain, or credible evidence of exploitation in the wild.

That distinction should not reduce the urgency. An unauthenticated Internet client can reach the vulnerable data-plane path when an affected build is actually serving HTTP/3 over QUIC. F5 says the result can be denial of service and that code execution is possible when Address Space Layout Randomization (ASLR) is disabled or bypassed. Administrators should patch now rather than waiting for a weaponized exploit.

Research checked August 2, 2026. This is a defensive analysis for system owners and incident responders. It intentionally omits exploit payloads, target-scanning instructions, heap-grooming recipes, and operational RCE steps.

The 30-second verdict

CVE-2026-42530 fact sheet

Field	Verified information
CVE	CVE-2026-42530
Vendor title	NGINX Open-Source ngx_http_v3_module vulnerability
Weakness	CWE-416: Use After Free
Affected upstream versions	NGINX Open Source 1.31.0–1.31.1
Fixed upstream version	1.31.2; 1.31.2+ listed as not vulnerable
Attack path	Remote HTTP/3/QUIC data plane; specially crafted session reopens a QPACK encoder stream
Privileges/user interaction	None / none
Attack complexity	High
CVSS v3.1	8.1 High — AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS v4.0	9.2 Critical — AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Disclosure	F5 advisory and NGINX 1.31.2 released June 17, 2026; F5 advisory updated June 22
Temporary mitigation	Remove quic from every listen directive; stop advertising HTTP/3 and close the UDP ingress path

Why “NGINX HTTP/3 RCE PoC” is too strong

There are three separate ideas being collapsed into one headline:

1. The vulnerability can corrupt memory. This is confirmed by the vendor, NGINX changelog, and researcher’s AddressSanitizer evidence.
2. The bug may lead to code execution. F5 says this is possible when ASLR is disabled or the attacker can bypass ASLR. The original researcher describes a controlled-write primitive and explains why that is powerful.
3. A public end-to-end RCE exploit exists. We did not verify this. The public repository most commonly labeled a PoC is a scanner/trigger. Its own documentation warns that a worker crash is possible but not reliable. It does not demonstrate a command shell, ASLR bypass, or post-exploitation control.

This is not hair-splitting. “Possible RCE” is the correct risk statement. “Public RCE implementation” implies that an attacker has already solved the hardest remaining problem and published a reliable chain. The sources reviewed for this article do not establish that.

What the public PoC actually does

A public GitHub repository from researcher Valton Tahiri describes itself as a scanner for CVE-2026-42530. We archived and reviewed the repository as text; we did not aim it at any public or third-party service.

At a high level, the probe makes an HTTP/3 connection and exercises the duplicate QPACK encoder-stream condition. It observes how the connection closes:

• A patched server should reject the duplicate critical stream with the HTTP/3 stream-creation error path.
• An affected server can accept the reopened encoder stream, reach freed memory, and close along the QPACK error path.
• The repository uses that behavioral difference to label the endpoint vulnerable or patched.
• The scanner’s own safety note says the trigger does not reliably crash a normal production worker, although a crash can occur depending on allocator layout.

Another public repository calls its script a “safe checker,” but our review found that its core decision is largely based on remotely advertised NGINX version information after an ordinary HTTP/3 request. That can be useful as a hint, but it is not dependable proof: server banners can be hidden, rewritten, backported, or belong to a different tier.

How the QPACK use-after-free happens

HTTP/3 runs over QUIC rather than TCP. QPACK, standardized in RFC 9204, compresses HTTP header fields while allowing QUIC streams to arrive out of order. A connection has dedicated unidirectional streams for QPACK encoder and decoder instructions.

The bug is fundamentally a lifetime mismatch:

1. The QPACK dynamic table belongs to the HTTP/3 session and lives for the connection.
2. The vulnerable insert buffer was allocated from the shorter-lived encoder stream’s memory pool.
3. When that stream closes, NGINX destroys the stream pool.
4. The session-level dynamic-table object can still hold a pointer into that freed pool.
5. A reopened encoder stream reaches the stale pointer, producing the use-after-free.

NGINX 1.31.2 addresses the structure of the bug instead of merely hiding the crash. The insert buffer is allocated from the parent QUIC connection pool so its lifetime matches the HTTP/3 session. The patched logic also retains a created-stream bit for the life of the session and rejects an attempt to reopen a critical stream type.

What the controlled-lab evidence proves

Trung Nguyen of CyStack published the most detailed technical analysis we found. In an AddressSanitizer build, the trigger produced a clear heap-use-after-free in the QPACK insert-buffer path. The allocation and free stacks point to the lifetime mismatch described above. On a normal glibc build, the researcher reports heap corruption and a worker segmentation fault.

The researcher also describes reclaiming the freed allocation with attacker-influenced data so the stale buffer object points at a chosen writable region. That produces a controlled-write primitive—a powerful building block for exploitation. However, the report explicitly says it does not demonstrate a complete RCE chain. The remaining obstacle is locating a useful address in a process protected by ASLR; the vulnerability itself does not provide an address leak.

Therefore, the responsible conclusion is:

• Worker crash/DoS: demonstrated and credible.
• Memory corruption: demonstrated and acknowledged upstream.
• Controlled-write primitive: described by the original researcher.
• Remote code execution: conditionally possible according to F5, especially where ASLR is disabled or defeated.
• Finished public RCE exploit: not verified.

Which systems are actually exposed?

An Internet-facing NGINX logo or TCP/443 listener is not enough. Treat a system as exposed when all three conditions apply:

1. It runs NGINX Open Source 1.31.0 or 1.31.1, or one of F5’s affected packaged-product releases.
2. The effective build and configuration serve HTTP/3/QUIC through ngx_http_v3_module.
3. Untrusted UDP traffic can reach that QUIC listener—commonly UDP/443—directly or through a load balancer, container port publication, Kubernetes Service, gateway, or host networking.

The HTTP/3 module is not built by default in a source build; it is enabled with --with-http_v3_module. NGINX’s binary packages may include QUIC/HTTP/3 support, but the attack path still depends on an active QUIC listener. If a CDN terminates HTTP/3 and forwards only ordinary TCP HTTPS to the NGINX origin, the origin may not receive attacker-controlled QUIC at all. Identify the component that actually terminates the protocol.

Affected F5 and NGINX product matrix

Product / branch	Known vulnerable	Fix introduced
NGINX Open Source 1.x	1.31.0–1.31.1	1.31.2
NGINX Instance Manager 2.x	2.17.0–2.22.0	2.22.1
NGINX Gateway Fabric 2.x	2.0.0–2.6.3	2.6.4
NGINX Gateway Fabric 1.x	1.3.0–1.6.2	No fix listed for that branch
NGINX Ingress Controller 5.x	5.0.0–5.5.0	5.5.1
NGINX Ingress Controller 4.x	4.0.0–4.0.1	No fix listed for that branch
NGINX Ingress Controller 3.x	3.5.0–3.7.2	No fix listed for that branch

F5 explicitly marks the following evaluated products/services not vulnerable: BIG-IP and BIG-IQ, BIG-IP Next SPK/CNF/for Kubernetes, F5 Distributed Cloud, F5 Silverline, NGINX One Console, F5OS-A, F5OS-C, Traffix SDC, F5 AI Gateway, and “NGINX all other products.” F5 also warns that releases beyond End of Technical Support were not evaluated, so an unlisted obsolete build must not automatically be treated as safe.

Safe checks administrators can run locally

Start inside the actual traffic-serving environment. A host’s NGINX package tells you little if traffic is handled by a container, appliance, ingress controller, or different binary path.

1. Confirm the running version and build options

nginx -v
nginx -V 2>&1

Keep the complete output internally. It records the binary version, build arguments, module options, and linked TLS library. Distribution vendors often backport fixes without changing the visible upstream version in the way a simple scanner expects, so validate the full package release against the supplier’s advisory.

2. Confirm the module and effective QUIC configuration

nginx -V 2>&1 | tr ' ' '\n' | grep -x -- '--with-http_v3_module'
nginx -T 2>&1 | grep -nE '^[[:space:]]*listen[[:space:]].*\bquic\b|Alt-Svc|^[[:space:]]*http3[[:space:]]'

nginx -T evaluates included configuration files, but its full output can contain sensitive internal details. Store and share it carefully. Strong exposure indicators include an effective listen 443 quic reuseport; line and an Alt-Svc response that advertises h3.

3. Verify the UDP listener and ingress layers

ss -H -lunp '( sport = :443 )'
lsof -nP -iUDP:443 2>/dev/null

A local socket does not prove Internet reachability, and a local firewall does not describe cloud security groups, load balancers, Kubernetes Services, anycast/CDN edges, NAT, or IPv6. Review every ingress layer. In Docker and Podman, TCP and UDP publication are separate; 443:443/tcp does not publish QUIC, while 443:443/udp can.

4. Check ASLR—but do not treat it as a patch

sysctl kernel.randomize_va_space

Full randomization raises the difficulty of turning an absolute-address write into code execution. It does not prevent the demonstrated worker crash/DoS outcome, and it does not prove that every possible ASLR bypass is unavailable. Keep ASLR enabled and patch anyway.

Immediate remediation

1. Inventory every NGINX data plane, including containers, ingress controllers, gateways, secondary regions, IPv6 listeners, and old canaries.
2. Upgrade through the authoritative supplier. The minimum upstream fix is 1.31.2. As of this article’s research cutoff, NGINX 1.31.3 was current and also contained later security fixes.
3. Verify package signatures or image digests. A mutable tag such as latest does not prove what is running.
4. Replace every worker, pod, or container. Updating files on disk while vulnerable workers continue running is not remediation.
5. Validate configuration and protocol behavior after rollout, then monitor for abnormal worker exits.

Temporary mitigation when an upgrade cannot happen immediately

F5’s explicit workaround is to remove quic from every listen directive. Preserve ordinary HTTPS over TCP so browsers can fall back:

# Keep ordinary HTTPS/TCP
listen 443 ssl;
listen [::]:443 ssl;

# Remove or comment every QUIC listener until fixed
# listen 443 quic reuseport;
# listen [::]:443 quic reuseport;

# Stop advertising HTTP/3 while it is disabled
# add_header Alt-Svc 'h3=":443"; ma=86400';

Also remove UDP/443 publication from containers, Kubernetes Services, cloud load balancers, host firewalls, and perimeter rules where appropriate. Clients may cache an Alt-Svc advertisement for its configured lifetime, so expect short-lived failed QUIC attempts followed by TCP fallback. Test any Alt-Svc: clear transition carefully because header inheritance can be subtle.

Validate before applying:

nginx -t

Use your organization’s normal change, reload, and rollback process. During a graceful reload, old workers can continue serving existing connections while they drain. For urgent containment, verify that no old worker retains the UDP socket.

Detection and incident-response clues

F5 has not published a unique network signature or log indicator for this CVE. The most defensible clues are repeated abnormal worker exits or kernel crash records that correlate with an affected HTTP/3 configuration and reachable UDP listener.

• Bursts of worker process ... exited on signal 11, SIGABRT, “segmentation fault,” or “core dumped.”
• Rapid worker PID turnover while the NGINX master process stays alive.
• QUIC/QPACK errors immediately before worker death.
• Availability alerts or unusual UDP/443 traffic at the same timestamps.
• Old container digests, deleted-but-mapped binaries, or stale pods left after an attempted update.

journalctl -u nginx --since '2026-06-17' --no-pager | grep -Ei 'worker process|exited on signal|segmentation fault|core dumped|quic|qpack|alert|emerg'
journalctl -k --since '2026-06-17' --no-pager | grep -Ei 'nginx|segfault|general protection|oom'
coredumpctl list nginx --since '2026-06-17' 2>/dev/null

These are triage signals, not proof of exploitation. NGINX workers can crash for many reasons, while successful exploitation might avoid obvious crash strings. Preserve relevant logs, core-dump metadata, process timelines, the exact package or image digest, effective configuration, and load-balancer records according to your incident-response policy. Do not reproduce the public trigger against production to “confirm” an incident.

Was it being exploited in the wild?

We found no primary-source statement that CVE-2026-42530 was under known active exploitation as of August 2, 2026. CISA’s SSVC enrichment recorded exploitation as “none” on June 17, and the CVE was absent from the CISA Known Exploited Vulnerabilities catalog version published July 29. F5, NGINX, NVD, and the CVE record did not report exploitation in the wild.

That is a dated evidence statement—not proof that exploitation has never happened or will not happen. Public trigger code and detailed root-cause analysis reduce an attacker’s research burden. The safe response is to patch based on exposure and impact, not wait for KEV inclusion.

Post-patch verification checklist

• Confirm the in-use package release or container digest, not just the downloaded image tag.
• Confirm no vulnerable worker process or stale pod remains.
• Run nginx -t and inspect effective configuration.
• If HTTP/3 remains disabled, confirm no listen ... quic, no NGINX UDP/443 socket, and no h3 advertisement.
• If HTTP/3 is restored, perform a loopback-only or authorized canary functional test with an HTTP/3-capable client.
• Check TCP HTTPS fallback, IPv4 and IPv6, each load-balancer path, and every region.
• Monitor worker restarts, QUIC errors, availability, and application latency after rollout.

Disclosure timeline

Date	Event
May 17, 2026	CyStack says the bug was identified on NGINX mainline 1.31.0.
May 18, 2026	The researcher reports stable AddressSanitizer and glibc worker-crash reproduction and submission to F5 through a coordinated GitHub Security Advisory.
June 2, 2026	CVE-2026-42530 was reserved.
June 17, 2026	F5 published K000161616; NGINX released 1.31.2 with the fix; the CVE and NVD record became public.
June 19, 2026	CyStack published its detailed technical analysis; public scanner repositories appeared after disclosure.
June 22, 2026	F5’s advisory shows its latest update date.
July 16, 2026	The CVE/NVD records were updated with additional supplier enrichment.
August 2, 2026	The IT Guys rechecked primary sources, CISA KEV status, public repositories, affected versions, and remediation guidance.

Common assessment mistakes to avoid

• Calling every older NGINX version vulnerable. The upstream range for this CVE is specifically 1.31.0–1.31.1. Version 1.30.x is not in that upstream range. Product vendors may backport fixes or bundle a different embedded component, so use their advisory rather than a crude version comparison.
• Trusting a remote Server header. A banner may be disabled, rewritten, stale, intentionally misleading, or generated by a CDN in front of the actual NGINX data plane. The running binary, package provenance, image digest, and effective configuration are stronger evidence.
• Confusing this with nearby NGINX CVEs. CVE-2026-42055 concerns a different HTTP/2/gRPC proxy buffer-overflow path, while CVE-2026-42533 involves map/regex handling. Their version ranges, prerequisites, fixes, and proof-of-concept claims must not be mixed with CVE-2026-42530.
• Assuming a public HTTP/3 response proves origin exposure. A CDN or load balancer may terminate QUIC at the edge and forward TCP to the origin. Trace the path and identify which component receives untrusted UDP.
• Pulling a patched image without redeploying it. Existing containers and pods continue running their old image ID. Verify the digest and the NGINX binary from inside every live workload after rollout.
• Forgetting old workers after a graceful reload. Old workers can retain sockets while draining. Confirm their process IDs disappear within the expected window and that no vulnerable binary remains mapped.
• Disabling all of port 443. The mitigation targets QUIC over UDP. Keep ordinary HTTPS over TCP/443 working unless your own design requires otherwise.
• Treating ASLR as a reason to postpone patching. ASLR complicates full code execution, but it does not remove the demonstrated unauthenticated worker-crash path.
• Running the trigger on production “just to see.” The scanner’s own documentation says a worker can crash depending on allocator state. Use configuration and artifact evidence first; reserve active validation for an isolated, authorized clone.

Frequently asked questions

Is CVE-2026-42530 a real NGINX vulnerability?

Yes. It is published in the CVE Program and NVD, listed by nginx.org, and covered by F5 Security Advisory K000161616. NGINX 1.31.2’s official changelog names the flaw and credits Trung Nguyen of CyStack.

Does it affect every NGINX server?

No. For upstream Open Source, the stated vulnerable range is narrowly 1.31.0–1.31.1, and the HTTP/3/QUIC module must be built and used. A reachable TCP/443 service alone does not establish exposure.

Is NGINX 1.30.x affected?

nginx.org does not list upstream stable 1.30.x as vulnerable to this CVE. Do not confuse CVE-2026-42530 with other NGINX flaws released nearby. Distribution and appliance packages should still be checked against their own advisories and backport records.

Is the public GitHub code an RCE exploit?

Not based on our review. The most relevant repository is a protocol-level trigger/scanner that distinguishes vulnerable and patched behavior. It can potentially destabilize an affected worker, but it does not demonstrate an ASLR bypass, command execution, or a shell.

Can the vulnerability still lead to code execution?

Potentially. F5 explicitly says attackers can execute code where ASLR is disabled or bypassed, and the original researcher describes a controlled-write primitive. That is why patching is urgent. The honest qualifier is that a complete public RCE chain was not verified.

Will disabling HTTP/3 break HTTPS?

Not if ordinary TCP HTTPS listeners remain correctly configured. Browsers should fall back to HTTP/2 or HTTP/1.1 over TCP. Remove the HTTP/3 advertisement and UDP ingress while preserving TCP/443, then test the site and API behavior.

Should we run the public PoC against our production server?

No. Start with version, package provenance, build flags, effective configuration, UDP reachability, and logs. If active testing is necessary, use a controlled, isolated, authorized clone with a rollback plan—not the live service.

Primary and technical sources

• F5 Security Advisory K000161616 — authoritative impact, product matrix, scores, and mitigation.
• NGINX security advisories — upstream affected and fixed range.
• NGINX CHANGES — 1.31.2 fix entry.
• CVE Program record — F5 CNA description, affected range, CWE, and scores.
• NIST NVD record — enrichment and product configurations.
• CyStack: Use-after-free in the QPACK encoder of nginx HTTP/3 — original detailed technical analysis and lab evidence.
• Official NGINX HTTP/3 module documentation — build and configuration requirements.
• RFC 9204: QPACK — protocol background.
• CISA Known Exploited Vulnerabilities Catalog — checked for exploitation status at publication time.
• Public scanner repository — included for evidence classification; do not run without authorization.

Attribution: F5 acknowledges Trung Nguyen of CyStack; Zhenpeng “Leo” Lin of depthfirst; Evan Hellman of Trail of Bits in collaboration with OpenAI; AntAISecurityLab; and Nebula Security for coordinated disclosure. NGINX’s changelog specifically thanks Trung Nguyen.

This article will be updated if F5, NGINX, CISA, or the original researchers publish verified new information about exploitation, an ASLR-bypass chain, or additional affected products.