Four security vulnerabilities have been found in the open source Ingress NGINX traffic controller that is extensively used by organizations in Kubernetes deployments.
They can only be fixed by upgrading to the latest version.
Of the four holes, two are more serious, because they carry CVSS scores of 8.8:
CVE-2026-1580 is an improper input validation issue. If the Ingress NGINX controller is configured with a default custom-errors configuration that includes HTTP errors 401 or 403, and if the configured default custom-errors backend is defective and fails to respect the X-Code HTTP header, then an Ingress with the auth-url annotation may be accessed even when authentication fails.
CVE-2026-24512 is a configuration injection vulnerability where the rules.http.paths.path Ingress field can be used to inject configuration into nginx. This can lead to arbitrary code execution in the context of the ingress-nginx controller, and disclosure of secrets accessible to the controller.
“This is a serious vulnerability,” commented Kellman Meghu, CTO of Canada’s DeepCove Cybersecurity, who has experience with Ingress NGINX. “If I could exploit it, I could get the Ingress gateway to create a path directly to internal resources. It’s like opening the insides that should never be exposed. Will that lead to further exposure or hacks? Probably, but in terms of impact, it’s a first step to gain access into the environment, and from there it could go further, the least of which would be disruption of services.”
NGINX is a reverse proxy/load balancer that generally acts as the front-end web traffic receiver and directs it to the application service for data transformation. Ingress NGINX is a version used in Kubernetes as the controller for traffic coming into the infrastructure. It takes care of mapping traffic to pods of containers running jobs without exposing the pods themselves. Meghu says Ingress NGINX is the primary traffic entry point, and is effective due to its ability to reload its configuration on the fly, allowing it to adjust to changes inside a Kubernetes cluster.
These vulnerabilities only affect Ingress NGINX versions 1.13.7 and below, and 1.14.3 and below, if they are installed on a Kubernetes cluster.
The warning comes just weeks before, as announced at KubeCon in November, support for Ingress NGINX ends. Starting in March, the project will no longer receive active maintenance, security patches, or bug fixes.
Experts have been urging Kubernetes administrators to shift to a new controller ever since. They recommend Kubernetes Gateway API as the standard for traffic management. Meghu notes it is vendor neutral and widely used. Other options are controllers such as Cilium Ingress, Traefik, or HAProxy Ingress.
In addition to CVE-2026-24512, the other new vulnerabilities are CVE-2026-24513, considered by Meghu a low risk since an attacker needs to have a config containing specific errors to exploit, and CVE-2026-24514, which Meghu considers a medium risk. The controller could be subject to a denial of service if an attacker overwhelms it with requests.
These are just the most recent issues with Ingress NGINX. Just over a year ago, researchers at Wiz discovered a group of holes dubbed IngressNightmare. They can allow unauthenticated users to inject malicious NGINX configurations and execute malicious code into the Ingress NGINX pod, potentially exposing all cluster secrets and leading to cluster takeover.
Satnam Narang, senior staff research engineer at Tenable, told CSO that he considers the new holes less concerning than IngressNightmare, which he called a “toxic combination” that could result in cluster takeover.
“While there’s nothing novel about [the new vulnerabilities], they serve as a stark reminder to all admins that if they haven’t started migrating, they need to start immediately, before Ingres NGINX is retired next month. Given its upcoming retirement, migration is the best strategy to mitigate these vulnerabilities.”