CVE-2026-42055: NGINX gRPC Heap Overflow Hits Ingress NGINX (2026)
How oversized headers in NGINX's HTTP/2 and gRPC proxy path corrupt worker memory and crash retired Ingress NGINX deployments

On June 17, 2026, F5 disclosed CVE-2026-42055, a critical heap-based buffer overflow (CWE-122) in NGINX's HTTP/2 and gRPC proxy modules. F5, the CNA, scores it 9.2 Critical on CVSS v4 (CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N) and 8.1 High on CVSS v3.1 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H). A remote, unauthenticated attacker can send oversized headers while NGINX is building an upstream request, corrupting worker-process memory and crashing it. It affects nginx Open Source 1.13.10 through 1.31.1 (and NGINX Plus R33 through 37.0.1), fixed upstream in 1.31.2 mainline and 1.30.3 stable. If you run end-of-life Ingress NGINX, that fix does not reach you on its own.
Running end-of-life Ingress NGINX? See NES for Ingress NGINX.
What is CVE-2026-42055?
CVE-2026-42055 is a heap-based buffer overflow (CWE-122) in two NGINX modules that proxy HTTP/2 to an upstream: ngx_http_proxy_v2_module and ngx_http_grpc_module. When NGINX constructs the upstream request, an attacker who can place oversized headers on that request can overflow a buffer in the worker process heap. The worker process is the part of NGINX that actually handles connections, so corrupting its memory is not a cosmetic bug. It crashes the process that is serving live traffic.
This is not a generic "send a big header and NGINX falls over" issue. It only fires when a specific, non-default proxy configuration is in place, which is exactly why the triage below matters before you panic or shrug.
Am I affected? A fast triage
"We run nginx" is not the answer to this one. CVE-2026-42055 needs four things to line up. Walk these in order. If any one of them is false, this specific bug does not apply to you (though CVE-2026-48142 below might).
- Which version? You are in range if you are on nginx Open Source 1.13.10 through 1.31.1, or NGINX Plus R33 through 37.0.1. The HeroDevs Ingress NGINX fork sits in this window on the gRPC path.
- Which module path? You are exposed only if you proxy HTTP/2 to an upstream, meaning a server or location block uses proxy_http_version 2 or grpc_pass. Plain HTTP/1.1 reverse proxying and TLS termination without HTTP/2 upstreams do not hit this code.
- Which header policy? You are exposed only if ignore_invalid_headers is set to off. The default is on, which rejects the malformed headers before they reach the vulnerable path.
- Which buffer size? You are exposed only if large_client_header_buffers is sized larger than 2 MB. The default is far smaller, so most deployments never reach the overflow condition.
All four have to be true at once. That is a real exposure for teams running gRPC ingress with tuned header handling, and it is a non-issue for a default config. Confirm your live config rather than assuming, because Ingress NGINX deployments accrete custom annotations and ConfigMap overrides over time.
Severity and exploit conditions
F5 published two scores. The headline figure is 9.2 Critical on CVSS v4. The CVSS v3.1 score is 8.1 High. The gap is not a contradiction: v4 and v3.1 weight the same facts differently, and both vectors mark Attack Complexity as High, which reflects the four-condition prerequisite above. NVD currently lists the entry as Undergoing Analysis, so the scores in NVD are F5's CNA values pending NVD's own review. Here is the v3.1 vector broken out.
CVE-2026-42055: CVSS v3.1 metric breakdown (8.1 High)
One honest note on scoring. Against the narrow real-world profile we ship for (gRPC proxy path only, with the four conditions), our internal exposure scoring puts this lower than the public figure, around 7.3. We still treat the public F5 score of 9.2 as the number that matters for your risk register, because your config, not ours, decides whether you are in the blast radius. The internal number is context, not a downgrade.
What an attacker can do
- Crash the worker handling the request. A single crafted request with oversized headers on the HTTP/2 or gRPC upstream path corrupts the worker heap and kills the process serving live connections.
- Drive a denial-of-service loop. Repeated requests force repeated crash-and-restart cycles. Because Ingress NGINX is the cluster's front door, sustained crashes can blackhole traffic to every service sitting behind that controller, not just the one app.
- Reach for code execution where ASLR is weak. A heap overflow in the worker context opens a path to remote code execution on systems where Address Space Layout Randomization is disabled or can be bypassed. F5 has not confirmed exploitation of CVE-2026-42055 in the wild, and we are not claiming it is. The point is that the ceiling on this bug is RCE, not just a crash.
- Do all of it unauthenticated. The CVSS vector is PR:N. An attacker needs network reach to a vhost using the affected proxy config and nothing else.
Who is affected?
CVE-2026-42055: affected versions and fix status
The distinction in the last row is the whole story for this post. Supported nginx has a fix you can pull today. The retired Ingress NGINX controller does not, because the project that would ship that fix is no longer maintaining it. More on that below.
CVE-2026-48142: charset module over-read
Disclosed alongside it on June 17, 2026, CVE-2026-48142 is a buffer over-read (CWE-125) in ngx_http_charset_module. It triggers when a location block is configured with both source_charset utf-8; and a charset directive (for example charset koi8-r;). A remote, unauthenticated request can then cause a heap buffer over-read in the worker process, leading to limited memory disclosure or a restart.
On severity, be precise. nginx.org rates this "low" in its own advisory tiering, but the F5 CNA CVSS scores put it in the Medium band: 4.8 on CVSS v3.1 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:L) and 6.3 on CVSS v4. Either way it is materially less severe than CVE-2026-42055: the impact is a memory over-read, not a write you can ride into code execution. It affects nginx 0.3.50 through 1.31.1 and is fixed in 1.31.2+ and 1.30.3+. Our Ingress NGINX fork is affected, and the fix ships in the same NES 1.15.6 release.
What about CVE-2026-42530 (the HTTP/3 bug)?
F5 disclosed a third NGINX CVE on June 17: CVE-2026-42530, a use-after-free (CWE-416) in ngx_http_v3_module, the HTTP/3 QUIC module, reachable by reopening a QPACK encoder stream. It is real and it is serious (9.2 Critical on CVSS v4), but it only affects nginx 1.31.0 and 1.31.1 and is fixed in 1.31.2. The HeroDevs Ingress NGINX fork is not on those versions, so CVE-2026-42530 does not affect it. If you came here asking whether the HTTP/3 bug touches your Ingress NGINX, the answer is no.
Why upgrading isn't the answer for EOL Ingress NGINX
The clean fix for a supported nginx is "move to 1.31.2 or 1.30.3." For Ingress NGINX, that path is closed. The Ingress NGINX controller is retired (see our Ingress NGINX end-of-life and migration guide for the full timeline and what retirement means in practice). A retired controller does not pick up the upstream nginx fix on its own, and there is no maintained release train to forklift onto without a migration project you may not be ready to run.
The risk of sitting on that gap is not theoretical. The last NGINX bug of this class, NGINX Rift (CVE-2026-42945), was disclosed on May 13, 2026 and reported exploited in the wild by VulnCheck within three days. EOL front-door infrastructure is a high-value target precisely because so many teams cannot patch it quickly. Treat the window between disclosure and a working fix as the window an attacker is also watching.
How HeroDevs handles it
Fixes for both CVE-2026-42055 and CVE-2026-48142 are merged into our Ingress NGINX fork as of June 19, 2026, are tested, and ship in the upcoming NES 1.15.6 release. The remediation is a drop-in replacement: you stay on Ingress NGINX, you pull the patched NES build, and you skip the migration project. NES customers stay protected on a controller that the upstream project has stopped maintaining, while an untouched EOL deployment stays exposed with no OSS fix coming.
Mitigation guidance
Mitigation guidance for CVE-2026-42055 and CVE-2026-48142
Related CVEs
This disclosure is part of the June 17, 2026 NGINX security batch and follows a recent run of NGINX heap issues. The directory entries below carry the per-CVE facts and catch the bare exact-ID search.
- CVE-2026-42055: NGINX HTTP/2 and gRPC proxy heap buffer overflow (this post's lead).
- CVE-2026-48142: NGINX charset module buffer over-read (disclosed in the same batch).
- CVE-2026-42945: NGINX Rift heap buffer overflow, the prior NGINX heap bug that was exploited in the wild within days of disclosure.
Taking action
CVE-2026-42055 is another reminder that EOL infrastructure does not get safer when the headlines move on. Supported nginx users have a clean upgrade to 1.31.2 or 1.30.3. Teams on the retired Ingress NGINX controller have no OSS fix, a known exploitation pattern for this bug class, and a migration project standing between them and safety.
If you run Ingress NGINX past end of life, NES for Ingress NGINX ships the fixes for both CVE-2026-42055 and CVE-2026-48142 in NES 1.15.6 as a secure drop-in replacement, so you stay patched without a forklift upgrade. To scope coverage for your environment, talk to our team or see pricing.
Our approach to vulnerabilities like this one is consistent across every ecosystem we support: identify what you are actually exposed to, remediate it without forcing a migration, and prevent the next gap before it becomes an incident.
Resources
View All Articles


