F5 says it has issued security updates for two critical NGINX vulnerabilities that could allow remote code execution in affected deployments under specific configurations.
The flaws are tracked as CVE-2026-42530 and CVE-2026-42055, both carrying a CVSS v4 score of 9.2. The practical takeaway for infrastructure and security teams is straightforward: check whether exposed NGINX systems use the affected HTTP/3 or HTTP/2 proxying paths, then move to fixed versions or apply the configuration mitigations where immediate patching is not possible.
Neither issue should be treated as a generic all-NGINX emergency without checking configuration. The attack conditions matter. One bug is tied to the HTTP/3 QUIC module and QPACK stream handling. The other depends on specific HTTP/2 proxy or gRPC settings, including relaxed invalid-header handling and oversized client header buffers.
What the two NGINX flaws affect
CVE-2026-42530 is a use-after-free vulnerability in ngx_http_v3_module. F5 describes the issue as reachable by a remote unauthenticated attacker when NGINX Open Source is configured to use the HTTP/3 QUIC module. The attack path involves reopening a QPACK encoder stream through a specially crafted HTTP/3 session.
The reported code-execution impact depends on systems where Address Space Layout Randomization is disabled or where an attacker can bypass ASLR. That condition does not make the issue low priority, but it does make environment review important before teams decide how broadly to emergency-change production traffic.
CVE-2026-42055 is a heap-based buffer overflow affecting ngx_http_proxy_v2_module and ngx_http_grpc_module. The vulnerable condition applies when NGINX is used to proxy HTTP/2 traffic with either the proxy_http_version 2 or grpc_pass directives, while ignore_invalid_headers is set to off and large_client_header_buffers is configured with a size larger than 2 MB.
In other words, the second flaw is most relevant to deployments that intentionally accept invalid headers and use unusually large client header buffers while proxying HTTP/2 traffic or gRPC requests.
Patch levels to check
The affected and fixed versions differ by product line, so teams should map their installed NGINX components before making assumptions. For NGINX Open Source, the fixes called out for these issues are 1.31.2 for the 1.31 branch and 1.30.3 for affected 1.30 releases.
| Vulnerability | Affected products and versions | Fixed version where listed |
|---|---|---|
| CVE-2026-42530 | NGINX Open Source 1.31.0 to 1.31.1 | 1.31.2 |
| CVE-2026-42530 | NGINX Gateway Fabric 2.0.0 to 2.6.3 | 2.6.4 |
| CVE-2026-42530 | NGINX Gateway Fabric 1.3.0 to 1.6.2; NGINX Instance Manager 2.17.0 to 2.22.0; NGINX Ingress Controller 5.0.0 to 5.5.0, 4.0.0 to 4.0.1, and 3.5.0 to 3.7.2 | Not listed in the provided version data |
| CVE-2026-42055 | NGINX Plus 37.0.0 to 37.0.1 | 37.0.2.1 |
| CVE-2026-42055 | NGINX Plus R33 to R36 | R36 P6 |
| CVE-2026-42055 | NGINX Open Source 1.31.1 | 1.31.2 |
| CVE-2026-42055 | NGINX Open Source 1.30.0 to 1.30.2 | 1.30.3 |
| CVE-2026-42055 | NGINX Instance Manager 2.17.0 to 2.22.0; F5 WAF for NGINX 5.9.0 to 5.13.1; NGINX App Protect WAF 5.2.0 to 5.8.0 and 4.10.0 to 4.16.0; F5 DoS for NGINX 4.9.0; NGINX App Protect DoS 4.3.0 to 4.7.0; NGINX Gateway Fabric 2.0.0 to 2.6.3 and 1.3.0 to 1.6.2; NGINX Ingress Controller 5.0.0 to 5.5.0, 4.0.0 to 4.0.1, and 3.5.0 to 3.7.2 | Gateway Fabric 2.6.4 where listed; other fixed versions not listed in the provided version data |
How to reduce exposure before patching
For teams that cannot immediately deploy the fixed builds, F5 lists configuration changes that can reduce risk.
- For CVE-2026-42530, disable HTTP/3 if the deployment uses the HTTP/3 QUIC module and cannot be patched right away.
- For CVE-2026-42055, remove the ignore_invalid_headers off directive from the NGINX configuration, or reduce the large_client_header_buffers directive size below 2 MB.
- Review whether proxy_http_version 2 or grpc_pass is used in the affected path, especially on internet-facing services and ingress layers.
- Prioritize fixes for systems where ASLR is disabled or where compensating controls are weak, since both vulnerability descriptions tie code execution to ASLR being disabled or bypassed.
These mitigations are not a substitute for upgrading, but they are useful triage steps when change windows, ingress-controller dependencies, or managed platform release timing slow down a full rollout.
What security teams should verify
The highest-value first check is configuration, not just package version. A fleet may contain vulnerable versions that are not using the exposed module or directive combination, while a smaller number of edge-facing systems may match the risky configuration exactly.
Security teams should inventory NGINX Open Source, NGINX Plus, Gateway Fabric, Ingress Controller, Instance Manager, App Protect WAF, F5 WAF for NGINX, and App Protect DoS deployments that fall into the affected ranges. From there, the review should focus on HTTP/3 enablement, HTTP/2 proxying, gRPC routing, invalid header handling, and oversized header buffer settings.
For buyers and platform owners, the bigger lesson is less about one patch cycle and more about knowing where NGINX sits in the stack. Ingress controllers, gateways, WAF modules, and proxy layers often live in different operational inventories, even when they are part of the same traffic path. That split can turn a straightforward patch advisory into a slower ownership problem.
The cleanest response is to patch the affected product lines, remove the risky configuration where possible, and keep a short list of exposed NGINX services that use HTTP/3, HTTP/2 proxying, or gRPC. That gives security teams a tighter view of where the real exposure sits instead of treating every NGINX instance as equally urgent.