F5 released out-of-band security patches for NGINX Open Source and NGINX Plus on 19 June 2026, addressing two critical vulnerabilities that carry CVSS scores of 9.2 and 8.7 respectively. The most severe, CVE-2026-42530, affects the HTTP/3 QUIC implementation in NGINX and can be exploited by an unauthenticated remote attacker to cause memory corruption and, under conditions where address space layout randomisation is disabled or bypassed, to achieve arbitrary code execution.

NGINX is one of the most widely deployed web servers and reverse proxies in the world. It handles traffic for a significant proportion of European enterprise infrastructure, typically positioned as the public-facing entry point for application stacks running on cloud or on-premises. A remotely exploitable, unauthenticated RCE vulnerability in NGINX’s network-facing HTTP implementation is a high-priority remediation item for any organisation running this software.

What CVE-2026-42530 does

The vulnerability exists in the ngx_http_v3_module, which handles HTTP/3 traffic over QUIC. HTTP/3 uses UDP rather than TCP as its transport layer and introduces a QPACK header compression mechanism that maintains state about the connection through encoder and decoder streams.

The flaw is classified as CWE-416: Use-After-Free. The specific trigger involves an attacker sending a specially crafted HTTP/3 session that causes NGINX to reopen a QPACK encoder stream. When this stream is reopened, the NGINX worker process accesses memory that has already been freed, causing memory corruption in the worker.

The immediate consequence is a crash of the NGINX worker process, resulting in a denial-of-service condition. Worker processes are automatically restarted by the NGINX master process, so the service interruption is brief, but repeated exploitation causes repeated restarts. More critically, under conditions where ASLR is disabled or where an attacker is able to bypass it through an information disclosure gadget, the memory corruption can be leveraged to achieve code execution in the context of the NGINX worker process.

The second vulnerability, CVE-2026-42055, affects the HTTP/2 module with a CVSS score of 8.7. Details on that flaw indicate it similarly enables denial-of-service and potential code execution, though specific technical details are not yet public.

Affected products

F5 has confirmed that the following NGINX products are affected by CVE-2026-42530:

• NGINX Open Source (all versions with HTTP/3 compiled and enabled)
• NGINX Plus (all versions with HTTP/3 configured)
• NGINX Gateway Fabric
• NGINX Instance Manager

The critical qualifier is that HTTP/3 support must be active. NGINX does not enable HTTP/3 by default. Deployments must have explicitly added QUIC support at compile time and configured listen directives with the quic parameter. Organisations that have not deliberately enabled HTTP/3 are not exposed to CVE-2026-42530, though they may still be affected by other vulnerabilities in the patch batch.

Immediate mitigation

For organisations that cannot deploy patches immediately, F5 has confirmed that disabling HTTP/3 is a complete mitigation for CVE-2026-42530. This involves removing the quic keyword from all listen directives in the NGINX configuration and reloading the service.

For example, a directive such as:

listen 443 quic reuseport;

should be changed to:

listen 443 ssl;

This change removes the attack surface for this specific vulnerability without affecting the server’s ability to handle HTTP/1.1 and HTTP/2 traffic. F5 explicitly states that this is a data plane issue with no control plane exposure, meaning the administrative interface and configuration management systems are not directly affected.

Patch availability

F5 has made patched versions of NGINX Open Source and NGINX Plus available through the standard release channels. The patched packages are available via the NGINX repository for supported Linux distributions and through the NGINX Plus customer portal.

For organisations using NGINX Gateway Fabric or NGINX Instance Manager, updated images and packages are available through the F5 support portal. The out-of-band nature of this release means it does not follow the standard NGINX release cadence and represents a targeted security fix rather than a feature release.

Why this matters for DevOps and platform teams

HTTP/3 adoption has been accelerating across European enterprise infrastructure through 2025 and into 2026. Several major cloud providers enable HTTP/3 by default for load balancers and CDN layers, and teams that have adopted NGINX Plus for API gateway or advanced traffic management roles have often enabled HTTP/3 as part of that deployment. The Cloudflare, AWS CloudFront, and Azure Front Door default configurations have normalised HTTP/3 expectations among developers, and NGINX Plus deployments serving applications to modern browsers have followed.

The result is that HTTP/3 is enabled in more NGINX production deployments than many teams are aware of. The first step in assessing exposure is an audit of NGINX configuration files across the estate. In Kubernetes environments, this includes checking the configurations of Ingress controllers and API gateways that run NGINX internally, as these often have different configuration management from standalone NGINX instances.

The second factor that elevates the risk profile of this vulnerability is the unauthenticated nature of the attack vector. HTTP/3 operates on UDP port 443, which must be open to the public internet for the protocol to function. An attacker does not need to obtain credentials, bypass authentication, or chain multiple steps to reach the vulnerable code path. A single crafted UDP packet sequence to port 443 of an exposed NGINX instance triggers the vulnerable code path. This makes the vulnerability trivially exploitable in network-accessible deployments.

The broader HTTP/3 security surface

CVE-2026-42530 is not the first security vulnerability in NGINX’s HTTP/3 implementation and is unlikely to be the last. HTTP/3 is a relatively recent addition to the protocol landscape, and QUIC’s statefulness and the QPACK header compression mechanism create a more complex attack surface than HTTP/1.1 or HTTP/2 at the transport layer.

For organisations that have enabled HTTP/3 primarily because it was available and enabling it seemed reasonable, this is an appropriate moment to evaluate whether the latency and connection establishment benefits of HTTP/3 justify the additional complexity and attack surface for their specific use case. For applications that serve predominantly European users on modern mobile networks where HTTP/3 provides measurable benefit, retaining HTTP/3 with a robust patching process is defensible. For internal applications, API backends, or infrastructure management interfaces that have no user-facing latency requirement, disabling HTTP/3 and accepting the simpler attack surface of HTTP/1.1 over TLS may be the more appropriate configuration.

What to do right now

Engineering and platform teams should take the following steps today:

Audit NGINX configurations for HTTP/3 usage. In most environments this means searching configuration files for quic in listen directives. The command grep -r "quic" /etc/nginx/ or equivalent covers standard deployments; Kubernetes Ingress controller configurations require checking the relevant ConfigMaps and Helm values.

Apply the F5 patches where HTTP/3 is needed. If HTTP/3 is deliberately enabled and provides measurable value, install the patched packages from the NGINX repository or F5 portal and reload the service. Validate that the patched version is running with nginx -v.

Disable HTTP/3 where it is not required. For deployments where HTTP/3 was not deliberately chosen or where the benefit is unclear, removing the quic listen parameter is a lower-effort and lower-risk option than patching, particularly in environments with change control processes that delay patch deployment.

Check Ingress controller versions. Kubernetes environments using the community NGINX Ingress Controller or the NGINX Plus Ingress Controller from F5 should check the upstream project for patched images. These projects typically release updated Docker images within days of upstream security fixes.

Monitor for exploitation attempts. CVE-2026-42530 will appear on scanner output and proof-of-concept code will likely be published within weeks of the patch release. Organisations that cannot patch or disable HTTP/3 immediately should ensure that their security monitoring includes NGINX worker crash events, which are logged to the error log and visible in system monitoring.

If your organisation needs help auditing NGINX configurations across an estate, assessing exposure to this vulnerability in Kubernetes or cloud environments, or building a process for timely web server security patching, contact Excello Digital. We work with platform and DevOps teams across Europe to maintain the security of web-facing infrastructure.