CRITICAL: F5 Patches Two NGINX Flaws Handing Unauthenticated RCE to Remote Attackers

If you run a website, an API gateway, an ingress controller, or a CDN edge, there is a non-trivial chance NGINX is somewhere in the path. F5 publishes the open source server that powers more than thirty percent of the busiest sites on the planet. On Wednesday and Thursday this week, F5 quietly dropped patches for two vulnerabilities that hand an unauthenticated remote attacker a credible path to remote code execution. Both score CVSS 4.0 9.2. Both live in modules that real production NGINX deployments use every day. Neither is being exploited in the wild yet, which is precisely the window where smart defenders move.

The two flaws are independent and target different sides of the same web server. CVE-2026-42530 is a use-after-free condition in ngx_http_v3_module, the module that handles HTTP/3 over QUIC. The bug lives inside the QPACK encoder stream logic, the piece of HTTP/3 that compresses header fields between the client and the server. A remote attacker who can speak HTTP/3 to a vulnerable instance can craft a session that reopens the QPACK encoder stream in a way the worker process is not prepared for. That dangling reference becomes a freed object that the worker keeps using. Use-after-free conditions in C code are reliable crashes at minimum and remote code execution at worst, gated only by Address Space Layout Randomization. On a hardened modern Linux box with ASLR enabled, the practical outcome is usually a worker crash and a denial of service. On an embedded appliance, a misconfigured container, or a system where ASLR has been disabled for performance reasons, that gate opens. Affected versions are NGINX Open Source 1.31.0 and 1.31.1, with the fix shipped in 1.31.2. The mitigation, if you cannot patch immediately, is to disable HTTP/3 entirely by removing the listen quic directive and the http3 directive from your configuration.

CVE-2026-42055 is a heap-based buffer overflow in the proxy and gRPC modules, specifically ngx_http_proxy_v2_module and ngx_http_grpc_module. This one is more situational but also more common in modern microservice stacks. The flaw triggers when NGINX is configured to proxy over HTTP/2 or gRPC and the operator has either turned off the ignore_invalid_headers check or pushed the large_client_header_buffers setting above two megabytes. Both of those are non-default but not exotic, and the combination shows up in production fairly often when teams are tuning for unusual workloads like large gRPC metadata payloads, federated authentication headers with bloated JWTs, or chatty service meshes that ship long correlation IDs around. Once those preconditions exist, an unauthenticated attacker who can route traffic through the proxy can deliver oversized headers that overflow a heap buffer in the worker process. Affected versions span an enormous range. NGINX Open Source from 1.13.10 through 1.31.2 and the 1.30.x stable line through 1.30.2 are all in scope, with patched builds shipping as 1.31.x and 1.30.3 for the stable branch. NGINX Plus customers running R33 through R36, as well as the 37.0.0 and 37.0.1 builds, need to move to 37.0.2.1 or R36 P6. If patching is genuinely impossible for the next day, removing the offending directives or pulling large_client_header_buffers back below two megabytes will close the door.

A quick word on the CVSS numbers, because they matter for how you triage. F5 scored both bugs at 9.2 under CVSS 4.0 and 8.1 under CVSS 3.1. The reason the older 3.1 score is lower is the attack complexity flag. Both vulnerabilities require some condition the attacker does not fully control, namely the ability to bypass ASLR for full code execution. CVSS 4.0 weighs that differently and surfaces the real impact more honestly. Treat these as critical. A skilled attacker who can reach the network port can knock workers over at will and, with patience, can chain an information leak into a working exploit. We have seen exactly that pattern play out in the last few years with NGINX Plus and Open Source bugs, and the proof of concept usually appears within a week or two of disclosure.

Who is affected. Anyone running NGINX as a reverse proxy, an API gateway, an ingress controller, or an edge load balancer, which is to say a very large share of the internet. NGINX Ingress Controller for Kubernetes, NGINX Gateway Fabric, and the F5 Distributed Cloud edge fleet all share the same code base and inherit both bugs in vulnerable versions. If your stack includes Istio with the legacy NGINX ingress, an OpenShift Router built on NGINX, or a managed Kubernetes service whose default ingress is NGINX, you are in scope. The same applies to CDNs and hosting providers that have not yet caught the patch wave. Roughly thirty-three percent of the top one million sites run NGINX in some form according to W3Techs, and a non-trivial slice of those are on the affected stable and mainline lines.

Exploitation in the wild has not been reported as of Friday morning. That window will not stay open. F5 vulnerabilities have an unfortunate track record. The BIG-IP iControl REST authentication bypass from a few years back went from advisory to mass exploitation in roughly a day. NGINX itself has historically been less of a magnet because the open source code base is smaller and better audited, but heap overflows and use-after-free conditions in HTTP parsers are catnip for exploit developers, and HTTP/3 in particular is still a relatively young attack surface. Expect proof-of-concept code to land on GitHub before the end of the month, and expect opportunistic mass scanning shortly after.

What to do. Patch is the answer, and the patches are out today. On the Open Source side, 1.31.2 closes the HTTP/3 bug, and the 1.30.3 stable build plus the 1.31.x mainline close the proxy and gRPC overflow. Plus customers move to R36 P6 or 37.0.2.1. For ingress controllers and managed Kubernetes ingress, check your vendor advisory. NGINX Ingress Controller, NGINX Gateway Fabric, and downstream rebuilds will have their own version numbers, and the timing between an upstream fix and a downstream image cut is usually a few hours to a few days. Pin the patched image as soon as your registry has it, and trigger a rolling restart rather than waiting for the next scheduled deployment.

If you are forced to wait, the mitigations are straightforward. Disable HTTP/3 by removing the listen 443 quic directive and the http3 on configuration line, which closes CVE-2026-42530 completely. For CVE-2026-42055, set ignore_invalid_headers back to its default of on or drop large_client_header_buffers below two megabytes, which removes the precondition the overflow requires. Neither is a permanent fix. Both buy you time.

Detection is harder than mitigation. There are no published indicators of compromise yet because there are no public exploits yet. The realistic detection plays are behavioral. Watch for worker process crashes and segmentation faults in your NGINX error logs, especially repeated crashes from the same client IP. Hunt for unusual HTTP/3 traffic patterns, including clients that aggressively open and close QPACK encoder streams within a single connection. On the proxy side, monitor for inbound requests with header values approaching or exceeding the configured large_client_header_buffers size, and treat repeated oversized header requests from a single source as suspicious. If you have a WAF in front of NGINX, push a rule that caps total header bytes at something sane like sixty-four kilobytes per request. That alone defangs the overflow even before you patch.

For MSPs and security service providers, this is a very clean conversation to have with clients today. NGINX sits in front of an enormous percentage of the web applications your customers depend on, and the version count in the average client environment is almost always wrong. Pitch an emergency patch sweep across customer ingress controllers, load balancers, and CDN edge configurations, billed as a one-time engagement. Then convert the win into an ongoing managed vulnerability program with monthly scoped patching windows and a Tenable or Qualys subscription bundled into the retainer. The upsell writes itself when the underlying story is that the most popular web server on the internet shipped two critical bugs and the client team has not patched them yet.