IngressNightmare: Critical Kubernetes Ingress Controller Flaws

• 25/3/2025
• 4-minute read

A set of recently discovered critical vulnerabilities dubbed “IngressNightmare” poses a significant threat to Kubernetes environments using the popular Ingress NGINX Controller. With a severity score of 9.8/10.0, these vulnerabilities allow unauthenticated attackers to achieve remote code execution and potentially gain complete administrative control over Kubernetes clusters.

Security researchers at Wiz identified this vulnerability suite affecting approximately 43% of internet-facing Kubernetes clusters. The potential impact is comparable to the infamous Log4Shell vulnerability, making immediate remediation essential for any organization using Kubernetes.

Understanding the IngressNightmare Vulnerabilities

The “IngressNightmare” comprises four distinct vulnerabilities in the admission controller component of the Ingress NGINX Controller:

*Some sources reference this as CVE-2025-24513

When chained together, these vulnerabilities allow attackers to execute arbitrary code and escalate privileges to gain administrator-level access to the entire Kubernetes cluster. The attack path requires network access to the admission controller endpoint of the Ingress NGINX Controller.

What Is Kubernetes Ingress and Why Is It Critical?

To understand the severity of these vulnerabilities, it’s important to know what Ingress controllers do in a Kubernetes environment:

Kubernetes Ingress is an API object that manages external access to services within a cluster, typically HTTP/HTTPS traffic. It provides capabilities such as:

• Defining externally accessible URLs for services
• Load balancing traffic
• Terminating TLS connections
• Name-based virtual hosting

The Ingress NGINX Controller implements the Ingress resource using NGINX as a reverse proxy and load balancer. Its position at the edge of your Kubernetes architecture makes it particularly sensitive from a security perspective.

For examples and more detailed information about these vulnerabilities, refer to the Wiz Security Blog.

Technical Analysis of the Vulnerabilities

The vulnerabilities exist in the admission controller component, which intercepts requests to the Kubernetes API server before object persistence. This component validates and potentially modifies these requests, making it a crucial control point for cluster configuration.

The injection vulnerabilities (CVE-2025-1097, CVE-2025-1098, and CVE-2025-24514) allow attackers to inject malicious code into the admission controller’s processing logic. This occurs because of improper validation of user-supplied input when converting between Kubernetes Ingress specifications and NGINX configuration directives.

The privilege escalation vulnerability (CVE-2025-1974) then allows attackers to elevate their privileges from the compromised admission controller to gain administrator-level access to the Kubernetes cluster.

Potential Impact

The consequences of a successful exploitation are severe:

1. Complete cluster takeover: Attackers can gain full administrator control over the entire Kubernetes cluster
2. Data exposure: Access to all secrets stored in the cluster, including API keys and credentials
3. Workload compromise: Ability to infect all workloads running in the environment
4. Lateral movement: Potential to pivot into other organizational systems using stolen credentials
5. Infrastructure manipulation: Control over all infrastructure managed through the Kubernetes API

Who Is Affected?

Organizations using Ingress NGINX Controller versions prior to 1.11.5 or 1.12.1 are vulnerable. According to research by Wiz, this includes:

• Over 6,500 internet-facing Kubernetes clusters
• Approximately 43% of all cloud environments
• Organizations across all industry sectors

Even clusters not directly exposed to the public internet can be vulnerable if an attacker gains network access through other means.

Mitigation and Remediation

Immediate Actions

1. Update Immediately: Upgrade your Ingress NGINX Controller to version 1.11.5, 1.12.1, or later.

2. Restrict Network Access: Implement strict network policies to ensure the admission webhook endpoint is not exposed externally.

3. Temporary Workaround: If immediate patching is not possible, consider temporarily disabling the admission controller functionality if not strictly required.

For detailed implementation examples and step-by-step instructions, refer to the Wiz Security Blog.

Long-term Security Measures

1. Regular Security Scanning: Implement vulnerability scanning for all Kubernetes components
2. Compliance Monitoring: Use tools like Trivy, Kubescape, or Falco to detect misconfigurations
3. Audit Logging: Enable comprehensive audit logging for Kubernetes API access
4. Implement Zero Trust: Apply the principle of least privilege across your Kubernetes environment

Comparison to Other High-Profile Vulnerabilities

The “IngressNightmare” vulnerability shares similarities with other significant security flaws:

Like Log4Shell, the widespread adoption of the vulnerable component and the simplicity of exploitation make “IngressNightmare” particularly concerning.

Conclusion

The “IngressNightmare” vulnerabilities represent a critical security risk for organizations using Kubernetes with the Ingress NGINX Controller. The combination of widespread deployment, ease of exploitation, and severe potential impact necessitates immediate action.

Organizations should prioritize patching these vulnerabilities as soon as possible and implement the recommended security measures to protect their Kubernetes environments. This incident serves as another reminder of the importance of continuous security monitoring and prompt patching in modern cloud-native environments.

Further Reading

• Wiz Security Blog
• Kubernetes Ingress Documentation
• Ingress NGINX Controller GitHub Repository
• Ingress NGINX Controller Release Notes
• Kubernetes Admission Controllers