CVE-2026-42055

This vulnerability involves how NGINX forwards (proxies) HTTP/2 or gRPC requests to another server. If certain settings are used together, a remote attacker can send unusually large “header” information that overflows a memory buffer inside NGINX, causing the NGINX worker to restart. In everyday terms, it’s like an input box that’s supposed to hold a certain amount of text, but under specific conditions the text can spill into the wrong memory area and make the service crash.

This matters to you if you run F5 NGINX Open Source or F5 NGINX Plus and you use the ngx_http_proxy_v2_module or ngx_http_grpc_module with proxying to HTTP/2 (via proxy_http_version 2) or gRPC (via grpc_pass). It specifically depends on configuration choices: ignore_invalid_headers set to off and large_client_header_buffers set larger than 2 megabytes. If you don’t use those directives/modules together, you may not be exposed, but you should check your NGINX configuration.

This is an AMBER issue because the reported bug can lead to a crash/restart of NGINX worker processes (a serious availability problem), and it was patched due to a new report. While there’s no known exploitation in the wild and no public exploit reported, attackers don’t need to have access to your system—only that your setup meets the risky configuration conditions. Treat it as something to fix during your next available maintenance window, sooner if your site is high-traffic or exposed to the public internet.

1. Identify exposure based on your configuration

• Confirm you run F5 NGINX Open Source or F5 NGINX Plus.
• In your NGINX config, check whether you use:
  • proxy_http_version 2 (for HTTP/2 proxying) and/or
  • grpc_pass (for gRPC proxying).
• Check whether ignore_invalid_headers is set to off.
• Check large_client_header_buffers—if the buffer size is larger than 2 megabytes, that increases the risk condition described.

2. Patch

• Update NGINX (F5 NGINX Open Source / F5 NGINX Plus) to the fixed release recommended by your vendor.
• If you manage multiple NGINX nodes, roll out the patch across them in a controlled manner (staged deployment first, then full rollout).

3. Configuration mitigation (if you can’t patch immediately)

• Reduce or remove the risky behavior tied to the conditions above:
  • Consider changing the proxy/gRPC setup so it no longer uses HTTP/2 proxying via proxy_http_version 2 and/or no longer uses grpc_pass with the vulnerable module path.
  • Set ignore_invalid_headers to on (since the issue requires it to be off).
  • Reduce large_client_header_buffers to a value not larger than 2 megabytes.
• After changing settings, test your HTTP/2 and gRPC traffic to ensure clients still work correctly.

4. Validate and monitor

• Monitor NGINX worker restarts/reloads and error logs around the time you deploy the fix.
• Watch for unusual request patterns with very large headers hitting your proxy/gRPC endpoints.
• If you use load balancing, ensure traffic is evenly distributed during/after the update so one node doesn’t get overloaded.

5. Confirm end-of-support isn’t involved

• The note says EoTS versions are not evaluated. If you’re on an End of Technical Support version, prioritize upgrading as part of your risk reduction plan.

Severity and status: Rated HIGH (CVSS 8.1). It is listed in CISA KEV as not known exploited in the wild. Public exploit availability is no; press attention is new, and press notes the issue was addressed by a patch. Exploitation status from press is none.

What’s vulnerable: ngx_http_proxy_v2_module and ngx_http_grpc_module in NGINX Plus and NGINX Open Source.

Key conditions: The bug triggers when:

• proxy_http_version 2 is used for HTTP/2 proxying and/or grpc_pass is used for gRPC proxying,
• ignore_invalid_headers is set to off, and
• large_client_header_buffers is configured with size greater than 2 megabytes.

Attack behavior: A remote, unauthenticated attacker (with conditions beyond their control) can send large headers while causing NGINX to create an upstream request. This may cause a heap-based buffer overflow in the NGINX worker process, leading to a restart.

Potential impact beyond crashing: The description also indicates attackers can execute code on systems where ASLR is disabled or could be bypassed.

About EPSS/KEV: KEV means CISA “Known Exploited Vulnerability” tracking; in this case it is not marked as known exploited. EPSS is a separate risk score system; it was not provided in your input, so its value is not stated here.

Attack vector summary: Remote network attacker sending oversized header data to endpoints that exercise the proxying/gRPC code paths under the vulnerable configuration.