On March 24th, 2025, Wiz’s research team published information on five vulnerabilities in the Ingress NGINX Controller for Kubernetes (ingress-nginx) that, when combined, would allow an unauthenticated attacker with access to the Ingress NGINX admission controller endpoint to execute code remotely and escalate privileges to cluster admin.
In this post, we examine the vulnerabilities, what steps are required to protect against these vulnerabilities, and how the Orca Cloud Security Platform can help.
Detailed overview
Referred to as ‘IngressNightmare,’ the vulnerabilities encompass three injection vulnerabilities (CVE-2025-1097, CVE-2025-1098, and CVE-2025-24514) and a privilege escalation vulnerability (tracked at CVE-2025-1974). These vulnerabilities create an attack vector that is rated CVSS 9.8, making them critical.
- CVE-2025-1097 – auth-tls-match-cn: This annotation tells NGINX to check the client certificate’s Common Name (CN) to decide if a client is allowed to connect. Due to the way NGINX Ingress validates the annotation value, an attacker can craft input to pass the validation and inject code into the NGINX config.
- CVE-2025-24514 – auth-url: In Kubernetes, NGINX Ingress allows you to define an auth URL that is used to send client requests to an external authentication service. But in older versions, there is not a proper sanitization process of this value before inserting it into the final NGINX configuration. This is dangerous because an attacker can simply add ‘;’ to the url and afterwards inject any malicious code they want.
- CVE-2025-1098 – mirror UID Injection: This vulnerability abuses the Ingress object’s UID field due to the fact that the UID is inserted directly into the NGINX config without any sanitization. So, if an attacker uses simple injection techniques (using ‘;’ and ‘#’ in the injected code) they can insert any code they want into the NGINX Ingress Controller.
- CVE-2025-1974 – NGINX Configuration Privilege escalation: This vulnerability, when combined with one of the three remote code execution vulnerabilities, enables privilege escalation. When NGINX reloads its configuration, it first runs nginx -t to test it with a highly privileged Kubernetes role. If attackers can sneak in a directive that causes code execution during this test, they can compromise the entire pod. Since, in the default configuration, the admission controller pod has access to all secrets in the cluster, this would give attackers access to the entire cluster and sensitive data used in the cluster in most cases.
Attackers can combine any of the injection vulnerabilities with the privilege escalation vulnerability to gain complete control of the Kubernetes cluster. An additional directory traversal vulnerability (CVE-2025-24513) is included in the disclosure.
Ingress-nginx allows for automatically configuring the NGINX reverse proxy for external access to Kubernetes workloads and is widely used. An admission controller is deployed as part of ingress-nginx in order to process new or changed Ingress objects. An attacker with network access to the admission controller can use any of the injection vulnerabilities in an unauthenticated payload sent directly to the admission controller. (Normally, only the Kubernetes API Server would send a payload to the admission controller.)
Affected versions and products
Ingress NGINX Controller for Kubernetes (ingress-nginx) with the following version numbers are affected:
- < v1.11.0
- v1.11.0 – 1.11.4
- v1.12.0
Fixes will be available in versions v1.11.5 and v1.12.1
While similarly named, NGINX Ingress Controller is a separate codebase and is reported to be unaffected.
Mitigation and response
Ensure that ingress-nginx admission controller endpoints are not publicly accessible and, if possible, can only be accessed from the Kubernetes API Server. If possible, disable the ingress-nginx admission controller until updates can be applied.
Apply fixes as soon as possible.
How the Orca Platform can help
The Orca Platform displays trending vulnerabilities in the “From the News” widget of the Orca dashboard. Users can see if their environment is vulnerable to any of the CVEs contained in this post and how to remediate them.
To find out if you are vulnerable to CVE-2025-1097, CVE-2025-1098, CVE-2025-24514, CVE-2025-1974, or CVE-2025-24513 in your environment, click the news item. This displays all assets with the CVE and enables you to click into each one to get details on the specific asset.
The Orca Cloud Security Platform identifies, prioritizes, and remediates risks across the multi-cloud environments of AWS, Azure, Google Cloud, Oracle Cloud, Alibaba Cloud, and Kubernetes. Using the Orca Platform, you can analyze vulnerabilities holistically in the context of your environment and surface toxic risk combinations that endanger your high-value assets. Orca also accelerates remediation with assisted and AI-driven remediation options, including generating AI-driven code fixes and instructions on command.
About Orca Security
We’re on a mission to provide the industry’s most comprehensive cloud security platform while adhering to what we believe in: frictionless security and contextual insights, so you can prioritize your most critical risks and operate in the cloud with confidence.
Unlike other solutions, Orca is agentless-first and fully deploys in minutes with 100% coverage, providing wide and deep visibility into risks across every layer of your cloud estate. This includes cloud configurations, workloads, and identities. Orca combines all this information in a Unified Data Model to effectively prioritize risks and recognize when seemingly unrelated issues can be combined to create dangerous attack paths. To learn more, see the Orca Platform in action.
