CVE-2026-42530: NGINX HTTP/3 QPACK Use-After-Free and RCE Risk

CVE-2026-42530 is a use-after-free vulnerability in the NGINX Open Source HTTP/3 implementation. A remote, unauthenticated attacker can send a specially crafted HTTP/3 session that reopens a QPACK encoder stream. The resulting memory-lifetime error can crash and restart an NGINX worker.

F5 also warns that code execution may be possible when Address Space Layout Randomization, or ASLR, is disabled or the attacker can bypass it.

The known affected range is unusually narrow: NGINX Open Source 1.31.0 through versions before 1.31.2. In practical terms, the published range covers versions 1.31.0 and 1.31.1. NGINX 1.31.2 is the upstream fixed release.

The vulnerability is serious, but it is configuration-dependent. A server is not exposed merely because NGINX is installed. The vulnerable ngx_http_v3_module path must be present, and the server must accept attacker-controlled QUIC and HTTP/3 traffic.

A server that only accepts HTTP/1.1 and HTTP/2 over TCP does not expose the specific HTTP/3 state involved in this vulnerability.

Organizations should take five immediate actions:

1. Identify every running NGINX Open Source 1.31.0 or 1.31.1 instance.
2. Determine whether each instance was built with HTTP/3 support and actively accepts QUIC traffic.
3. Map every UDP listener reachable from the internet or another untrusted network.
4. Upgrade exposed systems to NGINX 1.31.2 or an explicitly patched vendor package.
5. Investigate worker crashes, core dumps, repeated restarts and unusual QUIC traffic during the exposure period.

CVE-2026-42530 at a Glance

Product: NGINX Open Source

Affected module: ngx_http_v3_module

Vulnerability type: Use After Free, CWE-416

Trigger: A specially crafted HTTP/3 session reopens a QPACK encoder stream

Attacker position: Remote

Authentication required: No

User interaction required: No

Known affected versions: NGINX 1.31.0 and 1.31.1

Fixed version: NGINX 1.31.2

Primary consequence: NGINX worker crash and restart

Conditional worst-case impact: Code execution when ASLR is disabled or bypassed

CVSS 3.1: 8.1 High

CVSS 4.0: 9.2 Critical

Publication date: June 17, 2026

The two severity ratings are not contradictory. CVSS 3.1 and CVSS 4.0 are different scoring systems. F5 assigns a score of 8.1 High under CVSS 3.1 and 9.2 Critical under CVSS 4.0.

Security reports should always state the scoring version beside the number instead of selecting the more dramatic label without context.

Why HTTP/3 Changes the NGINX Attack Surface

HTTP/1.1 and HTTP/2 normally operate over TCP. HTTP/3 operates over QUIC, which uses UDP and integrates transport security with multiplexed streams.

An organization may therefore expose the same website through two distinct paths. TCP 443 may carry HTTP/1.1 and HTTP/2, while UDP 443 carries QUIC and HTTP/3.

The application behind NGINX may be the same, but the front-end protocol parsers are different. Blocking or inspecting TCP does not automatically control QUIC traffic. A WAF or load balancer that only terminates TCP may have no visibility into a directly exposed UDP listener.

CVE-2026-42530 exists in the HTTP/3-specific path. If an instance does not accept QUIC, an attacker cannot reach the vulnerable QPACK encoder-stream state through an ordinary HTTP/1.1 or HTTP/2 request.

This distinction is important for prioritization. Finding NGINX 1.31.1 in a software inventory establishes that vulnerable code may exist. It does not prove that the vulnerable code is remotely reachable.

What QPACK Does in HTTP/3

HTTP headers are repetitive. Requests frequently contain the same field names and recurring values, so transmitting every header literally would waste bandwidth.

HTTP/2 addresses this problem with HPACK. HTTP/3 uses QPACK, a compression scheme designed to work with QUIC’s independently delivered streams.

QPACK maintains compression state through a dynamic table. It also defines dedicated unidirectional streams:

The encoder stream sends instructions that update the peer’s decoder-side dynamic table.

The decoder stream carries acknowledgements and cancellation information in the opposite direction.

Each endpoint is permitted one encoder stream and one decoder stream for a connection.

That final rule matters for security. A QPACK encoder stream is not an ordinary request stream that a client can repeatedly open and close. It is connection-level protocol state with a defined lifecycle.

An HTTP/3 implementation must recognize a duplicate or invalid critical stream, terminate the relevant operation safely and ensure that every related object is released exactly once.

The F5 advisory states that a specially crafted session can reopen the QPACK encoder stream. This invalid state transition reaches an unsafe object-lifetime path in affected NGINX versions.

QPACK should not be confused with NGINX proxy caching, gzip compression or application cache headers. Disabling proxy_cache or gzip does not mitigate CVE-2026-42530.

How the Vulnerability Becomes a Use-After-Free

A use-after-free occurs when a program releases an object but later continues to access it through a stale pointer or reference.

In a network server, such objects may represent connections, streams, parsing state, buffers, event handlers or callbacks. Their lifetimes must remain synchronized across normal completion, protocol errors, timeouts and connection shutdown.

At a defensive level, the CVE-2026-42530 path can be understood as follows:

An attacker reaches an exposed QUIC listener.

An HTTP/3 connection establishes QPACK state.

The crafted session attempts to reopen the encoder stream.

Affected error handling releases an object while another usable reference remains.

The NGINX worker later accesses the released memory.

The worker crashes, or the corrupted memory is potentially used for further exploitation.

Freed memory does not necessarily become inaccessible immediately. Memory allocators often return the region to an internal free list. A later allocation may reuse the same region for another object.

If stale code subsequently reads or writes through the old pointer, the process may interpret unrelated or attacker-influenced data as legitimate object fields.

The most immediate consequence is commonly a segmentation fault. NGINX uses a master-and-worker architecture, so the master process can create a replacement worker after one crashes.

That design improves resilience, but it does not make the vulnerability harmless. Repeated crashes can reduce service capacity, terminate active connections, create core dumps and cause denial of service.

The more serious possibility is controlled memory corruption. Depending on allocator behavior, timing, binary layout and process hardening, an attacker may be able to influence pointers or control-flow data.

F5 therefore assigns high confidentiality, integrity and availability impact. The advisory states that code execution is possible when ASLR is disabled or the attacker can bypass it.

Why the Attack Complexity Is High

The CVSS 3.1 vector assigns high attack complexity. F5 also says exploitation depends on conditions beyond the attacker’s control.

The public advisory does not fully enumerate those conditions. They may involve object timing, heap layout, stream state or environmental behavior, but defenders should not present an unverified explanation as an official fact.

High attack complexity does not mean the vulnerability should be ignored. The attacker is remote, requires no account and needs no user interaction.

Internet-facing edge servers process large amounts of untrusted traffic. Attackers can repeatedly probe them, adapt attempts to common container images and study the fixed and vulnerable code.

The correct response is to patch and reduce exposure rather than rely on exploitation remaining difficult.

ASLR Is Not a Fix

ASLR randomizes the locations of executable code, shared libraries, stacks, heaps and other mappings. This makes it harder for an attacker to predict the addresses required for reliable control-flow hijacking.

F5 makes an important distinction:

The use-after-free can cause an NGINX worker to restart.

Code execution may be possible when ASLR is disabled or can be bypassed.

An affected system with ASLR enabled is still vulnerable. ASLR does not prevent the stale memory access and does not guarantee worker availability.

Information leaks, predictable container environments, non-position-independent components and other techniques may also weaken ASLR protection.

Organizations should keep ASLR enabled as a baseline control, but it must not be treated as remediation. The authoritative fix is patched NGINX code.

Which NGINX Systems Are Exposed?

The highest-priority condition is NGINX Open Source 1.31.0 or 1.31.1 with HTTP/3 enabled and a QUIC listener reachable from the internet.

An affected version with HTTP/3 enabled but restricted to an untrusted internal or tenant network should also receive high priority. Network restrictions reduce the number of potential attackers but do not eliminate malicious tenants, compromised systems or lateral movement.

If HTTP/3 support exists in the binary but no QUIC listener is active, the immediate exposure is lower. The software should still be patched because a future configuration change could reactivate the vulnerable path.

An affected NGINX instance serving only HTTP/1.1 and HTTP/2 over TCP does not currently expose the attack path described in the advisory.

NGINX Open Source 1.31.2 and later versions contain the upstream fix. Administrators must still verify that every active worker is running the updated binary.

Linux distributions may backport the fix into packages whose visible upstream version appears older. In those cases, check the full package revision and the distribution’s security advisory.

F5 also states that software versions beyond End of Technical Support were not evaluated. An unsupported version missing from the affected list should not be treated as proven safe.

The CVE record specifically names NGINX Open Source. NGINX Plus, ingress controllers, appliances, managed proxies and third-party forks may have different branches or patch schedules. Consult the relevant product advisory instead of automatically applying the Open Source version table.

How to Check Exposure Safely

Start by checking the runtime version:

nginx -v

nginx -V

The first command reports the upstream version. The second also provides configure arguments and relevant build information.

Do not rely only on a Dockerfile, package manifest or image tag. A host may continue running an old process after a package update, and a mutable container tag may refer to different images across environments.

On Debian-derived systems, record the package revision with:

dpkg-query -W nginx nginx-core nginx-full

On RPM-based systems, use:

rpm -qa | grep -i ‘^nginx’

Next, inspect the effective configuration:

nginx -T

Look for QUIC listeners, normally represented by a listen directive using the quic parameter. Protect this output because it may expose certificate paths, upstream names and other operational details.

Alt-Svc headers can indicate that clients are being invited to use HTTP/3. However, an Alt-Svc header does not prove that the vulnerable NGINX process terminates QUIC. A CDN or external load balancer may handle QUIC before forwarding TCP traffic to the origin.

Inspect UDP listeners with:

ss -lunp

Map UDP 443 and any custom QUIC port to its process, container, service and external load balancer.

For Kubernetes environments, inspect workloads and services:

kubectl get deploy,daemonset,statefulset -A -o wide

kubectl get svc -A -o wide

kubectl get svc -A -o yaml

Look for UDP service ports, NGINX image digests, command-line arguments and mounted configuration.

The decisive question is not simply whether the website advertises HTTP/3. It is whether an untrusted party can deliver QUIC packets to an affected NGINX worker.

Check public exposure, VPN access, partner networks, multi-tenant networks, internal lateral paths and direct origin addresses.

A useful verification record should contain:

The complete runtime version and package revision.

The nginx -V build information.

The effective QUIC configuration.

UDP listener ownership.

External and internal network reachability.

The container image digest or host package identifier.

The vendor advisory establishing fixed status.

The deployment and restart record after remediation.

Automated validation can help correlate these elements. A platform such as Penligent can associate asset, version, configuration and reachable-service evidence so teams do not confuse a package match with a confirmed attack path. Automated conclusions should still retain the underlying evidence and clearly state what was actually verified.

How to Fix CVE-2026-42530

The recommended fix is to upgrade NGINX Open Source to version 1.31.2 or later.

If NGINX comes from a Linux distribution, container supplier, appliance or managed platform, install the vendor release explicitly documented as containing the CVE-2026-42530 fix.

A safe rollout should include these steps:

Record the current runtime binary, package revision, image digest, build flags and configuration.

Obtain the patched package or image from a trusted supplier.

Verify the artifact according to the organization’s software supply-chain policy.

Run nginx -t against the intended configuration.

Deploy through a canary or staged edge pool where possible.

Restart or gracefully reload NGINX using the supported operational process.

Confirm the master and every worker are using the patched binary.

Test HTTP/3, HTTP/2 and HTTP/1.1 behavior.

Monitor errors, connection establishment and worker lifecycle during rollout.

An installed package update does not automatically prove remediation. Old workers may remain during a graceful transition, an orchestrator may recreate pods from an old image digest, or one region may lag behind the rest.

Runtime verification is essential.

Temporary Mitigations

If an upgrade cannot be completed immediately, remove the vulnerable protocol path from untrusted reachability.

The strongest temporary mitigation is to disable HTTP/3 and QUIC on affected NGINX instances. Remove or disable the QUIC listener, validate the configuration with nginx -t and reload NGINX through the supported process.

Stop advertising HTTP/3 through Alt-Svc if clients would otherwise continue attempting the QUIC path.

HTTP/1.1 and HTTP/2 can normally continue over TCP while UDP and QUIC are disabled. This behavior should be tested in the actual architecture.

Another option is to block the affected UDP port at a cloud security group, load balancer, firewall, Kubernetes Service or edge ACL.

Confirm that no custom QUIC port, direct origin address or internal path remains reachable. Document the mitigation with an owner and expiration date so that HTTP/3 is not re-enabled before patching.

Several controls are not equivalent to a fix:

Application authentication does not help because malformed HTTP/3 state is processed before application authorization.

HTTP Basic Authentication does not make the protocol parser memory safe.

A traditional WAF may not inspect the relevant QUIC state.

TCP-only firewall policies do not control UDP traffic.

Rate limiting may reduce repeated crashes but does not remove the vulnerability.

Running multiple workers may improve availability but does not stop exploitation.

ASLR may reduce exploit reliability but does not prevent the underlying use-after-free.

Detection Opportunities

There is no vendor-published universal exploit string for CVE-2026-42530. Detection should combine process, host and network evidence.

Investigate NGINX error-log entries showing a worker exiting on signal 11 or another fatal signal.

Review systemd and journald for repeated worker deaths and replacement events.

Search kernel logs for segmentation faults associated with the NGINX binary.

Protect and analyze relevant core dumps. Core files may contain request data, cryptographic material and credentials.

Review container and Kubernetes events for restart spikes or liveness failures. Note that NGINX can replace a worker without restarting the whole container.

Use QUIC-aware load-balancer telemetry to identify malformed sessions, critical-stream violations and unusual connection churn.

Examine network telemetry for repeated short UDP 443 sessions, unusual source concentrations and spikes in QUIC connection failures.

Monitor endpoint and runtime security tools for unexpected child processes, executable mappings, file changes and outbound connections.

A worker crash does not automatically prove exploitation of this CVE. Many unrelated software and operational issues can produce the same symptom.

Correlate crashes with the affected version, active QUIC configuration, network traffic and core-dump evidence.

Likewise, a lack of application log entries does not prove that no attack occurred. The failure may happen in the HTTP/3 protocol layer before an ordinary application request is logged.

الاستجابة للحوادث

Treat a crash on an exposed NGINX 1.31.0 or 1.31.1 HTTP/3 server as an investigative lead.

Preserve NGINX logs, journald records, kernel messages, container events, load-balancer telemetry, flow records and available packet metadata.

Secure any core dump because it may contain sensitive process memory.

Record the exact binary hash, package revision, image digest, configuration, linked libraries, worker start times and ASLR state.

Remove the affected QUIC listener from untrusted traffic or drain the node.

Upgrade or rebuild the service from a trusted patched artifact rather than returning the same vulnerable runtime to production.

Examine the host or container for unexpected processes, modified files, credential access, suspicious executable memory and unusual outbound connections.

Rotate credentials available to the worker if code execution is suspected or runtime integrity cannot be established.

Hunt across other edge nodes for similar crashes, source infrastructure and traffic patterns.

NGINX workers commonly run under a dedicated unprivileged account. This can reduce the immediate impact of successful code execution, but it does not make compromise harmless.

The worker may still access TLS material, upstream tokens, mounted files, internal networks, service-mesh credentials and proxied request data. Assess the actual runtime permissions instead of relying on the word “unprivileged.”

How to Verify the Fix

Verification should prove both that patched code is running and that legitimate protocol behavior still works.

Confirm that nginx -v reports version 1.31.2 or a vendor-documented patched build.

Confirm the package revision or image digest matches the approved artifact.

Confirm every worker started after the new binary was installed.

Check that no old pod, node, region or autoscaling template can reintroduce NGINX 1.31.0 or 1.31.1.

Establish normal HTTP/3 connections through an authorized test client.

Verify valid requests, responses, headers, redirects and connection reuse.

Test HTTP/2 and HTTP/1.1 negotiation and fallback.

Confirm Alt-Svc advertising matches the intended deployment state.

Verify UDP load balancing, health checks, observability and graceful reload behavior.

In an isolated and authorized environment, a qualified team may use reviewed regression tests to confirm safe handling of invalid critical streams.

Do not aim an unreviewed public proof of concept at production. Patched runtime evidence, ordinary protocol tests and clean worker telemetry provide a safer production verification method.

Long-Term NGINX Hardening

CVE-2026-42530 demonstrates why protocol enablement must be part of attack-surface management.

An SBOM may show that NGINX exists, but it does not tell the security team whether UDP 443 reaches ngx_http_v3_module.

Maintain an inventory of enabled protocol modules, listeners and network paths alongside package versions.

Keep edge software on a supported release line with an emergency patch process.

Run workers as a dedicated least-privilege account.

Restrict Linux capabilities and unnecessary writable paths.

Use read-only container filesystems where operationally feasible.

Apply seccomp, AppArmor, SELinux or another runtime confinement layer.

Keep private keys and upstream credentials outside the worker process where architecture permits.

Restrict outbound network access from edge proxies.

Centralize worker-exit and core-dump telemetry.

Test an HTTP/3 rollback procedure so QUIC can be disabled without disrupting TCP service.

Track image digests and package revisions rather than mutable tags.

Include UDP exposure in firewall, cloud and Kubernetes reviews.

The NGINX worker model is useful for availability, but automatic worker replacement should not conceal memory-corruption signals. Replacement is a recovery mechanism, not a security verdict.

Frequently Asked Questions

Does CVE-2026-42530 affect every NGINX server?

No. The published affected product is NGINX Open Source 1.31.0 through versions before 1.31.2. The vulnerable path is in ngx_http_v3_module, and the server must accept attacker-controlled HTTP/3 traffic.

Is HTTP/3 enabled automatically?

Do not assume that it is. Exposure depends on the build, effective listener configuration and network path. Check nginx -V, nginx -T, UDP listeners and load-balancer configuration.

Are NGINX 1.30.x and older versions affected?

They are not included in the published affected range. However, F5 states that versions beyond End of Technical Support were not evaluated. An unsupported version that is absent from the list should not automatically be considered safe.

Does the vulnerability guarantee remote code execution?

No. The vendor describes worker restart as the immediate result. Code execution is possible when ASLR is disabled or can be bypassed. The official CVSS vector also assigns high attack complexity.

Does enabling ASLR fix the vulnerability?

No. ASLR may reduce exploit reliability, but the use-after-free still exists and can still crash a worker. Upgrade to patched NGINX code.

Can blocking UDP 443 mitigate the issue?

Blocking the real QUIC listener removes the published external attack path while the block remains complete. Check for custom UDP ports, direct origin access and internal network paths. Treat this as a temporary mitigation.

Will a WAF stop the attack?

Only a product that terminates and safely processes QUIC is positioned to affect the relevant protocol state. Traditional HTTP WAF rules may operate after the vulnerable parsing has already occurred.

How can I determine whether exploitation occurred?

Review fatal worker signals, core dumps, restart patterns and QUIC telemetry. Then search for unexpected processes, file changes, credential access and outbound connections. No single log entry proves or disproves compromise.

What if my distribution reports an older upstream version?

Check the complete package revision and the distribution’s security advisory. Vendors often backport patches without replacing the upstream version string.

Does the CVE affect NGINX Plus or ingress controllers?

The CVE record specifically names NGINX Open Source. Consult the advisory for the relevant commercial product, ingress controller, appliance or managed platform instead of copying the Open Source version range.

Is active exploitation known?

The CISA ADP enrichment attached to the CVE record marked exploitation as “none” on June 17, 2026. This is a time-bound observation, not proof that exploitation cannot occur or has not happened in a particular environment.

الخاتمة

CVE-2026-42530 is a remotely reachable memory-safety vulnerability in the NGINX HTTP/3 edge. Accurate triage, however, requires more than matching the NGINX product name.

The highest-risk combination is specific: NGINX Open Source 1.31.0 or 1.31.1, active HTTP/3 and QUIC support, and an attacker-accessible UDP listener.

The response order is straightforward. Verify the running version, inspect the effective QUIC configuration, map UDP reachability, upgrade to NGINX 1.31.2 or a vendor-confirmed patched build, and investigate worker crashes and protocol anomalies.

If an immediate upgrade is impossible, disable or block the QUIC path. Do not rely on application authentication, TCP-only controls, WAF rules or ASLR as substitutes for a patch.

The larger lesson is simple: versions matter, but reachable protocol state is what turns installed code into an attack surface.