Critical Ingress NGINX Controller Vulnerabilities Expose Kubernetes Clusters to Remote Code Execution

A Major Security Threat to Kubernetes

A newly discovered set of five critical vulnerabilities in the Ingress NGINX Controller for Kubernetes—collectively named IngressNightmare—has raised serious security concerns. These vulnerabilities allow unauthenticated remote code execution (RCE) and put over 6,500 Kubernetes clusters at immediate risk.

Cloud security firm Wiz identified these vulnerabilities and assigned them CVE-2025-24513, CVE-2025-24514, CVE-2025-1097, CVE-2025-1098, and CVE-2025-1974, with a maximum CVSS severity score of 9.8. If exploited, attackers can compromise the entire cluster, gaining unauthorized access to secrets stored across namespaces.

Security teams managing Kubernetes deployments must take immediate action to patch affected versions, restrict external access to admission controllers, and implement necessary mitigations to prevent exploitation.

Understanding the IngressNightmare Vulnerability

Ingress NGINX Controller is a widely used reverse proxy and load balancer that enables external HTTP/HTTPS traffic to reach services within a Kubernetes cluster. It relies on an admission webhook to validate and modify Kubernetes API requests before they are applied.

The problem lies in how the admission controller is implemented. The component is exposed without authentication, making it accessible to attackers who can inject malicious ingress objects into the system. By crafting specific AdmissionReview requests, attackers can manipulate NGINX configurations, achieve remote code execution, and ultimately take over the Kubernetes cluster.

Breakdown of Each CVE in IngressNightmare

CVE-2025-24513 (CVSS 4.8) – Directory Traversal & Partial Secret Disclosure

• This flaw stems from improper input validation, allowing attackers to traverse directories within the container.
• While it primarily leads to denial-of-service (DoS) attacks, it can also cause limited exposure of Kubernetes secrets if combined with other vulnerabilities.
• Attackers could potentially access sensitive configuration files within the pod, escalating their foothold within the cluster.

CVE-2025-24514 (CVSS 8.8) – Code Injection via auth-url Annotation

• The auth-url Ingress annotation is intended to define an authentication endpoint for requests.
• However, due to a lack of validation, attackers can inject arbitrary configuration directives into NGINX.
• This results in remote code execution (RCE) inside the Ingress NGINX Controller’s pod, exposing Kubernetes secrets across namespaces.

CVE-2025-1097 (CVSS 8.8) – Code Injection via auth-tls-match-cn Annotation

• Similar to CVE-2025-24514, this vulnerability exploits the auth-tls-match-cn annotation, which is meant to enforce TLS client certificate validation.
• Attackers can manipulate this annotation to modify NGINX configurations dynamically.
• The flaw enables execution of arbitrary code within the ingress controller’s pod, allowing unauthorized access to stored credentials.

CVE-2025-1098 (CVSS 8.8) – Code Injection via mirror-target & mirror-host Annotations

• This vulnerability arises from the mirror-target and mirror-host Ingress annotations, which are used to duplicate HTTP traffic for testing and analysis.
• Attackers can inject malicious directives through these annotations, achieving remote code execution within the ingress controller’s pod.
• It provides a direct pathway to exfiltrate sensitive data or further compromise Kubernetes secrets.

CVE-2025-1974 (CVSS 9.8) – Unauthenticated Remote Code Execution (RCE) via Admission Controller

• This is the most severe vulnerability in the set, allowing unauthenticated attackers to exploit the admission controller directly.
• By crafting a malicious AdmissionReview request, attackers can modify NGINX configurations to execute arbitrary code.
• If the admission controller is exposed externally, it enables full cluster compromise with no authentication barriers.

How Attackers Exploit IngressNightmare

Security researchers have demonstrated a potential attack scenario that follows this sequence:

1. Locate Exposed Admission Controllers
2. Send Malicious AdmissionReview Requests
3. Inject Malicious Code
4. Trigger Remote Code Execution
5. Compromise the Entire Cluster

Who is at Risk?

Security firm Wiz estimates that 43% of cloud environments using Kubernetes are vulnerable to IngressNightmare. The issue is particularly concerning for:

• Organizations running multi-tenant Kubernetes clusters, where a breach could expose secrets across multiple namespaces.
• DevOps teams that have exposed admission webhooks to external networks, increasing the attack surface.
• Companies that haven’t updated to the latest Ingress NGINX Controller versions.

It is important to note that IngressNightmare does not affect the NGINX Ingress Controller for Kubernetes, which is a separate implementation.

Mitigation and Security Recommendations

1. Patch Immediately

The vulnerabilities have been addressed in Ingress NGINX Controller versions 1.12.1, 1.11.5, and 1.10.7. Organizations must update immediately to prevent potential exploitation.

2. Restrict Admission Controller Exposure

Security teams should ensure that the admission webhook endpoint is not exposed externally. The Kubernetes API Server should be the only entity allowed to interact with the admission controller.

3. Disable the Admission Controller if Not Required

If the admission controller component is not necessary, consider disabling it to reduce attack vectors.

4. Monitor for Malicious AdmissionReview Requests

Implement logging and monitoring for unusual AdmissionReview API requests. Any unexpected ingress object modifications should be investigated.

5. Enforce Strong Role-Based Access Control (RBAC)

Restrict Ingress Controller permissions to prevent lateral movement within the Kubernetes environment.

A Wake-Up Call for Kubernetes Security

The IngressNightmare vulnerabilities serve as a stark reminder of the security risks associated with Kubernetes misconfigurations and exposed components. Attackers are constantly looking for ways to exploit weaknesses in cloud environments, and organizations must remain vigilant in securing their infrastructure.

The immediate priority for security teams is to patch vulnerable versions, restrict admission controller access, and implement strict monitoring and access controls. As Kubernetes adoption grows, organizations must recognize that security is not just an afterthought but an essential part of their cloud strategy.

The question is no longer if attackers will target Kubernetes environments—it’s when. Will your organization be prepared?