Security Intelligence
Loading table of contents...
At a glance: F5 released updates on June 17, to fix two critical NGINX vulnerabilities that allow remote, unauthenticated exploitation under specific configurations. The flaws can lead to service outages and, in certain conditions, remote code execution on systems handling internet-facing traffic. Organizations using NGINX as a reverse proxy or gateway face elevated risk due to its central role in routing application traffic.
Threat summary
On June 17, U.S.-based cybersecurity and application delivery company F5 released out-of-band security updates to address multiple vulnerabilities in NGINX.
These updates include fixes for two critical flaws affecting NGINX Open Source, NGINX Plus, and related components such as NGINX Ingress Controller and Gateway Fabric. The flaws enable denial of service and, under certain conditions, remote code execution due to memory corruption issues.
As of June 19, there is no evidence of active exploitation in the wild.
NGINX is an open-source web server and reverse proxy widely used to route and manage web traffic. It sits in front of applications and handles load balancing, traffic routing, and Transport Layer Security (TLS) termination. F5 acquired NGINX in 2019 and now maintains both the open-source project and its commercial offerings, including NGINX Plus and related platforms.
The two critical flaws, both rated with the Common Vulnerability Scoring System (CVSS) version 4.0 score of 9.2, are tracked as CVE-2026-42530 and CVE-2026-42055.
Both vulnerabilities can be triggered remotely without authentication, which means a threat actor only needs network access to a vulnerable NGINX service. There is no need for valid credentials or prior access.
The trigger depends on specific features being enabled, such as HTTP/3 (for CVE-2026-42530) or certain HTTP/2 and gRPC proxy configurations (for CVE-2026-42055). When these features are active, a specially crafted request can reach the vulnerable code paths.
At a technical level, both flaws are memory corruption issues.
- CVE-2026-42530 is a use-after-free condition, where NGINX continues to use memory that has already been released. It affects the HTTP/3 module (ngx\_http\_v3\_module) and is triggered through crafted HTTP/3 QUIC sessions.
- CVE-2026-42055 is a heap-based buffer overflow, where more data is written into memory than the allocated space allows. It affects HTTP/2 proxy and gRPC handling modules (ngx\_http\_proxy\_v2\_module and ngx\_http\_grpc\_module).
In both cases, the normal memory handling of the application breaks, and the NGINX worker process encounters an unexpected state.
The immediate outcome is usually a worker process crash. NGINX handles traffic using multiple worker processes. When one crashes, it causes interruptions in handling client requests. If the issue is triggered repeatedly, it can lead to continuous crashes, effectively creating a denial-of-service condition where the application becomes unavailable or unstable.
Remote code execution becomes possible under additional conditions tied to memory protection. Modern systems use protections such as Address Space Layout Randomization (ASLR) to randomize where code and data are stored in memory. This makes it difficult for a threat actor to predict where to place malicious instructions. If ASLR is disabled, misconfigured, or bypassed, the memory corruption can be controlled more reliably. In that case, instead of just crashing the process, the threat actor can influence execution flow and run their own code on the system.
Affected versions include:
- NGINX Open Source 1.31.0 through 1.31.1, with fixes available in 1.31.2, as well as earlier supported branches such as 1.30.x, fixed in 1.30.3.
- Exposure also extends to products built on the same codebase, including NGINX Gateway Fabric versions 2.0.0 through 2.6.3, fixed in 2.6.4, and older Gateway Fabric 1.x versions that do not yet have a fix available.
- NGINX Ingress Controller versions across 3.x, 4.x, and 5.x are affected with no direct fix at the time of disclosure, and NGINX Instance Manager versions 2.17.0 through 2.22.0 are impacted through underlying components.
Other NGINX-based products not using the affected components are not vulnerable.
Analysis
In practical terms, these flaws introduce two levels of risk. The second is full system compromise, which requires additional conditions but allows arbitrary code execution on the host running NGINX. Because NGINX sits in front of applications, the impact can extend beyond a single service and affect every backend system behind it.
The impact includes disruption at the application edge, loss of availability, and potential compromise of the underlying host. As a reverse proxy, NGINX controls traffic entering and leaving backend systems. A successful compromise provides visibility and control over that traffic, creating a path to inspect, modify, or redirect requests. The worst-case scenario involves adversary-controlled code execution on edge infrastructure combined with traffic manipulation across multiple applications behind a single proxy layer.
Affected environments include internet-facing NGINX deployments using HTTP/3, HTTP/2 proxying, or gRPC configurations, as well as systems running NGINX-based ingress controllers or edge gateways. Exposure depends on how these features are configured and whether the affected modules are in use.
F5 released fixes on June 17, 2026, including patched versions such as NGINX Open Source 1.30.3 and 1.31.2, along with updates for supported Gateway Fabric releases. Some dependent components, including NGINX Ingress Controller and certain management and protection modules, did not receive immediate fixes. This creates a window where configuration-based actions help reduce exposure.
Upgrading to fixed versions removes the vulnerable code paths tied to HTTP/3 and HTTP/2 processing. Where upgrades are delayed, exposure can be reduced by disabling HTTP/3 and adjusting proxy configurations that allow unsafe header handling. Reducing large client header buffer sizes and keeping header validation enabled further limits risk. Ongoing review of edge configurations helps confirm that vulnerable modules are not active.
Priority should be given to internet-facing NGINX instances and environments using QUIC or gRPC. Systems that rely on NGINX as a central traffic gateway would benefit from quick validation and a phased rollout of updates to keep services running while reducing exposure.
Stay on top of emerging threats like this.
Sign up to receive a weekly roundup of our security intelligence feed. You'll be the first to know of emerging attack vectors, threats, and vulnerabilities.
