CVE-2026-42530 & CVE-2026-42055: F5 Patches NGINX Vulnerabilities

F5 has released out-of-band security updates for two NGINX vulnerabilities that can affect exposed web infrastructure: CVE-2026-42530 and CVE-2026-42055.

The first issue affects NGINX’s HTTP/3 QUIC handling. The second affects specific HTTP/2 and gRPC proxying configurations. Both can be triggered remotely and may cause NGINX worker processes to restart, creating a Denial-of-Service (DoS) risk. F5 also notes that code execution may be possible in some scenarios, depending on the affected issue and deployment conditions.

What Did F5 Fix in NGINX?

On June 17, 2026, F5 issued an out-of-band notification regarding NGINX security patches tracked as CVE-2026-42530 and CVE-2026-42055. The official NGINX advisory classifies CVE-2026-42530 as a major-severity use-after-free in HTTP/3, and CVE-2026-42055 as a medium-severity buffer overflow affecting gRPC and HTTP/2 proxying modules.

What Is CVE-2026-42530?

CVE-2026-42530 (CVSS 8.1) is a use-after-free vulnerability in NGINX’s HTTP/3 implementation, specifically in the ngx_http_v3_module.

The issue matters when NGINX exposes HTTP/3 over QUIC. In that setup, a remote attacker can send crafted traffic that causes an NGINX worker process to restart. CVE-2026-42530 is especially important to track, as exposed HTTP/3 deployments may face Remote Code Execution (RCE) risk.

• NGINX versions 1.31.0 through 1.31.1 are identified as vulnerable to this CVE.
• NGINX versions 1.31.2 or later are confirmed as not vulnerable.

Researchers also track CVE-2026-42530 under the name nginx-quicburst. A public video demonstration is also available, which may increase interest in the vulnerability and help defenders understand how the issue behaves in practice.

What Is CVE-2026-42055?

CVE-2026-42055 (CVSS 7.3) is a heap-based buffer overflow affecting NGINX HTTP/2 and gRPC proxying paths.

This vulnerability does not apply equally to every NGINX instance. It depends on a specific configuration pattern involving HTTP/2 or gRPC upstream proxying. F5’s advisory describes the affected area as the ngx_http_proxy_v2_module and ngx_http_grpc_module, and notes that the issue can allow a remote, unauthenticated attacker to trigger a worker process restart.

• NGINX versions 1.13.10 through 1.31.1 are listed as vulnerable.
• NGINX versions 1.30.3, 1.31.2, or later are confirmed as not vulnerable.

Which NGINX Deployments Are Most Exposed?

The highest-risk deployments are the ones where the vulnerable feature path is reachable from untrusted networks.

For CVE-2026-42530, focus on systems that expose HTTP/3 over QUIC, commonly through UDP/443. If HTTP/3 is not enabled, this specific attack path should not be reachable externally.

For CVE-2026-42055, review NGINX instances that proxy traffic to HTTP/2 or gRPC upstreams. Risk increases when the deployment uses non-default header handling, especially configurations that disable invalid-header filtering or allow unusually large client headers.

Security teams should prioritize:

• Internet-facing NGINX servers with HTTP/3 enabled
• Reverse proxies handling gRPC services
• API gateways using HTTP/2 upstream proxying
• Ingress tiers with relaxed header validation
• High-availability systems where repeated worker restarts can cause user-facing outages

How Could Exploitation Affect Operations?

For CVE-2026-42530, an attacker would target the HTTP/3 QUIC listener. The attacker does not need credentials or user interaction. Repeated attempts could restart worker processes and degrade availability.

For CVE-2026-42055, the attacker must reach a vulnerable HTTP/2 or gRPC proxying path. This makes edge reverse proxies and API gateways especially important, since they often sit between external users and critical backend services.

Even when an exploit only causes worker restarts, the impact can be serious. NGINX often supports authentication portals, APIs, customer-facing applications, and ingress traffic. Instability at this layer can quickly become a broader service issue.

Is There Evidence of Active Exploitation?

At the time of writing, public reporting did not identify confirmed in-the-wild exploitation for CVE-2026-42530 or CVE-2026-42055. However, both issues are remotely triggerable, and researcher attention is already visible through public discussion and demonstration material.

Security teams should not wait for confirmed exploitation before acting. Once technical details become easier to reproduce, exposed NGINX deployments may become attractive targets.

What Should Security Teams Do Now?

Patch affected NGINX versions

Upgrade affected deployments to fixed versions:

• CVE-2026-42530: upgrade to NGINX 1.31.2 or later
• CVE-2026-42055: upgrade to NGINX 1.30.3, 1.31.2, or later, depending on the branch

Organizations using F5-packaged NGINX products should follow the relevant F5 guidance for their product line, not only the open source version table. Security teams can review the official F5 vendor notice here.

Reduce exposure before patching is complete

If patching requires staging, reduce access to the vulnerable paths where possible.

For CVE-2026-42530, disable HTTP/3 where the feature is not required. For CVE-2026-42055, review HTTP/2 and gRPC proxying locations, especially configurations with relaxed header validation or large header buffers.

Monitor for worker instability

Investigate repeated NGINX worker restarts, abnormal QUIC traffic, unusual HTTP/2 or gRPC errors, and unexpected spikes in malformed or oversized requests.

These signals do not prove exploitation on their own, but they can help teams identify suspicious activity while patches are being deployed.

How Can SOCRadar Help?

Vulnerability response becomes harder when teams cannot quickly identify where a risky service is exposed. For NGINX issues like these, defenders need to know which assets are internet-facing, which versions are running, and which services expose HTTP/3, HTTP/2, or gRPC paths.

SOCRadar’s Attack Surface Management (ASM) can help security teams discover exposed NGINX assets across their external attack surface. Its Vulnerability Intelligence capabilities, offered by the Cyber Threat Intelligence module, can also support prioritization by tracking affected technologies, public exploit activity, and vendor guidance as the situation develops.