CVE-2026-42055
This Vulnerability has been fixed in the Never-Ending Support (NES) version offered by HeroDevs.
Overview
Ingress NGINX Controller is an ingress controller for Kubernetes that uses NGINX as a reverse proxy and load balancer. It embeds an NGINX Open Source build and generates NGINX configuration from Ingress objects and annotations, so an NGINX-layer flaw ships inside the controller image rather than being something the cluster operator compiled directly. It is one of the most widely deployed ingress controllers in production Kubernetes clusters, routing external HTTP/HTTPS traffic to Services running inside the cluster.
A heap-based buffer overflow (CVE-2026-42055) has been identified 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, a remote, unauthenticated attacker who can place oversized headers on that request can overflow a buffer in the worker-process heap, corrupting the memory of the process serving live connections and crashing it. On systems where ASLR is disabled or can be bypassed, the same primitive raises the ceiling from denial of service to remote code execution.
Per OWASP: a buffer overflow occurs when a process writes data beyond the bounds of an allocated memory region, corrupting adjacent state in a way that can crash the service or be steered into arbitrary code execution.
This issue affects NGINX Open Source 1.13.10 through 1.31.1 and NGINX Plus R33 through R37.0.1, and every downstream that compiles the affected modules, including the upstream Ingress NGINX Controller v1.15.1. Upstream NGINX shipped the fix in 1.31.2 (mainline) and 1.30.3 (stable) on June 17, 2026. The Kubernetes ingress-nginx project retired in March 2026 at v1.15.1 and will not ship a release that absorbs the fix.
Why this matters for Ingress NGINX deployments
This bug does not fire on a default configuration. It requires a specific, non-default proxy setup, which is exactly why triage matters before you panic or shrug. But where the conditions are met, the exposure sits at the cluster edge: the corrupted process is the one terminating external TLS and routing traffic to every Service behind the controller. For teams on upstream Ingress NGINX v1.15.1, scanners report CVE-2026-42055 as an open Critical once NVD propagates the advisory, and no upstream release will close it. NES for Ingress NGINX rebases the controller's compiled NGINX with the patched modules, closing the finding without a configuration change or a Gateway API migration.
Am I affected? A fast triage
"We run nginx" is not the answer. CVE-2026-42055 needs a vulnerable version plus three configuration conditions to line up at once. If any one is false, this specific bug does not apply.
- Which version? In range if you are on NGINX Open Source 1.13.10 through 1.31.1, or NGINX Plus R33 through R37.0.1. The Ingress NGINX v1.15.1 build sits in this window on the gRPC path.
- Which module path? 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 reach this code.
- Which header policy? 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? 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.
You need a vulnerable version and all three configuration conditions true simultaneously.. That is a real exposure for teams running gRPC ingress with tuned header handling, and a non-issue for a default config. Confirm your live configuration rather than assuming, because Ingress NGINX deployments accrete custom annotations and ConfigMap overrides over time.
Details
Module Info
- Product: NGINX (ngx_http_proxy_v2_module, ngx_http_grpc_module); compiled-in component of Ingress NGINX Controller
- Affected components: the HTTP/2 and gRPC upstream-proxy request-construction path, reachable only with proxy_http_version 2 or grpc_pass, ignore_invalid_headers off, and large_client_header_buffers sized above 2 MB
- Affected versions: NGINX Open Source 1.13.10 through 1.31.1; NGINX Plus R33 through R37.0.1; Ingress NGINX Controller builds that link those versions, including upstream v1.15.1
- Upstream source repository: https://github.com/nginx/nginx
- Container image (community, affected): registry.k8s.io/ingress-nginx/controller
- Helm chart (community): https://kubernetes.github.io/ingress-nginx
- Distribution channels: container registry (registry.k8s.io), Helm, kubectl manifests
- Fixed in:
- nginx 1.31.2 (mainline) and 1.30.3 (stable), June 17, 2026 (upstream). Credited to Mufeed VH of Winfunc Research.
- NES for Ingress NGINX 1.15.6, merged June 19, 2026, which backports the upstream fix onto the controller's pinned NGINX baseline (see release notes)
Vulnerability Info
This Critical-severity vulnerability lives in the code path that builds an upstream request when NGINX proxies HTTP/2 or gRPC to a backend.
When a server or location block is configured to proxy HTTP/2 upstream (proxy_http_version 2 or grpc_pass), NGINX assembles the upstream request, including client-supplied headers, into a worker-process heap buffer. Under the default header policy (ignore_invalid_headers on), malformed or oversized headers are rejected before they reach this path. The vulnerable condition arises when an operator has set ignore_invalid_headers off and sized large_client_header_buffers above 2 MB: an attacker can then place oversized headers on the request being constructed and overflow the heap buffer in the worker process.
The worker process is the part of NGINX that handles live connections, so corrupting its memory is not cosmetic. The reliable outcome is a crash of the worker serving the request. Because the overflowed bytes are attacker-influenced, the ceiling is higher: on systems where ASLR is disabled or can be bypassed, a heap overflow in the worker context opens a path to remote code execution. F5 has not confirmed in-the-wild exploitation of CVE-2026-42055.
Threat model for Ingress NGINX clusters: exploitation requires a vulnerable build plus the three-condition configuration above. No authentication is required; the attacker needs network reach to a vhost using the affected proxy configuration and nothing else. The AC:H metric reflects the three-condition prerequisite and the ASLR dependency for code execution.
When successfully exploited, this vulnerability can lead to:
- Crash of the worker handling the request via a single crafted request with oversized headers on the HTTP/2 or gRPC upstream path
- A sustained denial-of-service loop through repeated crash-and-restart cycles; because the controller is the cluster's front door, sustained crashes can blackhole traffic to every service behind it, not just one app
- Remote code execution in the worker context on systems where ASLR is disabled or can be bypassed
- All of the above unauthenticated (PR:N): the attacker needs only network reach to a vhost using the affected proxy config
Severity and exploit conditions
F5, acting as CNA, published two scores: 9.2 Critical on CVSS v4.0 (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). The gap between the two is not a contradiction; v4.0 and v3.1 weight the same facts differently, and both vectors mark Attack Complexity as High, reflecting the three-condition prerequisite. NVD lists the entry as undergoing analysis at the time of writing, so the NVD figures are F5's CNA values pending NVD's own review.
Against the narrow real-world profile relevant to Ingress NGINX (the gRPC proxy path with the three conditions met), HeroDevs internal exposure scoring places this around 7.3. The public F5 score of 9.2 remains the number that matters for a risk register, because your configuration, not the fork's defaults, decides whether you are in the blast radius. The internal number is context, not a downgrade.
Exploitation status
F5 has not confirmed in-the-wild exploitation of CVE-2026-42055, and there is no public proof of concept at the time of writing. The prior NGINX heap 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, so the window between disclosure and a working fix should be treated as the window an attacker is also watching.
Steps To Reproduce
- Stand up a controller running upstream Ingress NGINX v1.15.1 (or any NGINX build between 1.13.10 and 1.31.1).
- Configure a server or location block to proxy HTTP/2 upstream (proxy_http_version 2 or grpc_pass), set ignore_invalid_headers off, and size large_client_header_buffers above 2 MB.
- Send a crafted request carrying oversized headers on the HTTP/2 or gRPC upstream path.
- Observe the worker process crash and restart in the controller logs. Repeat to demonstrate a sustained denial-of-service loop.
Proof Of Concept
No weaponized exploit code is published. The three-condition trigger and the affected module path described above are sufficient to determine exposure and remediate.
Mitigation
OSS Users
Users of upstream NGINX and Ingress NGINX should apply one of the following mitigations:
- Upgrade NGINX Open Source to 1.31.2 (mainline) or 1.30.3 (stable) and restart workers. The same release also fixes CVE-2026-48142 (charset-module over-read) disclosed in the same batch.
- As a configuration stopgap on builds that cannot be patched immediately, restore the default header policy (ignore_invalid_headers on) and/or reduce large_client_header_buffers below the vulnerable threshold, breaking the three-condition prerequisite. Verify against the live configuration.
- For Ingress NGINX specifically, no upstream release will rebase against the patched NGINX because the project retired in March 2026. Sign up for post-EOL security support; HeroDevs customers get immediate access to a patched Ingress NGINX build.
NES Customers
HeroDevs Never-Ending Support for Ingress NGINX resolves CVE-2026-42055 in NES for Ingress NGINX 1.15.6 (merged June 19, 2026) by backporting the upstream fix onto the controller's pinned NGINX baseline. The release ships the fixes for both CVE-2026-42055 and CVE-2026-48142 as a drop-in replacement for upstream ingress-nginx v1.15.1: you stay on Ingress NGINX, pull the patched NES build, and skip the migration project. VEX statements ship with the release so scanners that consume OpenVEX or CycloneDX VEX surface the patched status. See the NES for Ingress NGINX release notes for image tags and Helm chart versions.
Related CVEs
- CVE-2026-48142: the NGINX charset-module buffer over-read disclosed in the same June 17 batch; fixed in the same NES 1.15.6 release.
- CVE-2026-42533: the NGINX map/regex script-engine heap overflow that also lands on EOL Ingress NGINX.
- CVE-2026-42945: "NGINX Rift," the prior NGINX heap bug reported exploited in the wild within days of disclosure.
Note on CVE-2026-42530 (an HTTP/3 use-after-free disclosed in the same June 17 batch): it affects only NGINX 1.31.0 and 1.31.1 and is fixed in 1.31.2. The Ingress NGINX v1.15.1 build is not on those versions, so CVE-2026-42530 does not affect it. For the full deep-dive, see the CVE-2026-42055 blog post, and browse the full vulnerability directory.
Compliance impact
CVE-2026-42055 is a Critical, unauthenticated, network-reachable flaw at the cluster edge for deployments that meet its configuration prerequisites. Several frameworks make the gap acute for teams on an EOL controller:
- The EU Cyber Resilience Act's Article 14 reporting obligations begin September 11, 2026.
- DORA's ICT third-party risk requirements have been in force since January 2025.
- PCI DSS 4.0 expects continuous evidence that components receive security patches.
- FedRAMP authorizations carry continuous monitoring obligations.
The NES release ships a documented patch trail plus VEX statements that scanners consume programmatically.
Taking Action
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. NES for Ingress NGINX 1.15.6 ships the fixes for both CVE-2026-42055 and CVE-2026-48142 as a secure drop-in replacement, so you stay patched without a forklift upgrade. To scope coverage, see NES for Ingress NGINX or talk to our team.
Credits
- Mufeed VH, Winfunc Research (finder)
- F5 (CNA; advisory and CVSS scoring)
- HeroDevs NES for Ingress NGINX engineering (downstream backport and rebuild)
References
