F5 Patches Two Critical NGINX Flaws for Remote Code Execution

NGINX is the reverse proxy running quietly behind a significant share of the internet's HTTP infrastructure, which makes two critical patches from F5 this week worth stopping on. Both vulnerabilities, covered by The Hacker News, carry a CVSS score of 9.2 and enable remote code execution: CVE-2026-42530, a use-after-free in NGINX's HTTP/3 QUIC module, and CVE-2026-42055, a heap-based buffer overflow in the HTTP/2 proxy and gRPC modules.

The two flaws have meaningfully different exploitability profiles. CVE-2026-42530 requires ASLR to be disabled or bypassed, which raises the practical bar on modern hardened systems. CVE-2026-42055 requires a specific combination of four conditions to be in place simultaneously: proxy_http_version set to 2, grpc_pass directives in use, ignore_invalid_headers set to off, and large_client_header_buffers exceeding 2 MB. That specificity limits exposure but does not make the risk theoretical, particularly for teams that have tuned their NGINX configurations for performance or gRPC workloads.

Fixes land in NGINX Open Source 1.31.2, NGINX Plus 37.0.2.1, Open Source 1.30.3, and NGINX Gateway Fabric 2.6.4, along with multiple Ingress Controller versions. For teams that cannot patch immediately, F5 provides actionable mitigations: disable HTTP/3 for the first flaw, and remove the ignore_invalid_headers directive or reduce large_client_header_buffers below 2 MB for the second. That makes this a relatively well-served critical disclosure compared to many.

The timing adds context. A prior critical NGINX flaw, CVE-2026-42945, reportedly experienced active exploitation within days of its disclosure. Two more 9.2-rated vulnerabilities arriving in that flaw's wake suggests the NGINX codebase is attracting sustained security scrutiny, which cuts both ways: bugs are being found and fixed, but adversaries are also paying close attention. For teams running NGINX as a reverse proxy or Kubernetes ingress controller, the answer is straightforward: patch promptly and run a configuration audit.

The honest caveat is that the article does not detail whether proof-of-concept code exists for either flaw, and the real-world exploitability of CVE-2026-42530 hinges entirely on the ASLR posture of each specific deployment. What the reporting does not give you is data on how common the vulnerable four-condition configuration combination is in practice, which makes the audit as important as the patch itself.