Understanding the Critical IngressNightmare Vulnerabilities in Kubernetes
The Kubernetes community was recently alerted to a set of critical vulnerabilities in the widely-used Ingress NGINX Controller, collectively dubbed "IngressNightmare." These vulnerabilities, including CVE-2025-1974, CVE-2025-1097, CVE-2025-1098, and CVE-2025-24514, have received a CVSS score of 9.8 (Critical) and could potentially allow attackers to execute remote code on affected clusters.
With approximately 43% of cloud environments vulnerable and over 6,500 clusters exposed, this security issue demands immediate attention from DevOps and security teams. In this post, we'll explore these vulnerabilities and provide guidance on how to protect your Kubernetes infrastructure.
Understanding the IngressNightmare Vulnerabilities
The Ingress NGINX Controller is one of the most popular ingress controllers for Kubernetes, responsible for managing external access to services within a cluster. The recently discovered vulnerabilities affect the admission controller component of Ingress NGINX and could allow attackers to:
- Execute arbitrary code on the Ingress NGINX Controller's pod
- Gain unauthorized access to secrets across all namespaces
- Achieve complete cluster takeover
The vulnerabilities specifically allow attackers to inject arbitrary NGINX configuration remotely by sending malicious ingress objects to the admission controller. The four main vulnerabilities are:
- CVE-2025-24514 (auth-url Annotation Injection): Allows injecting arbitrary NGINX configuration directives
- CVE-2025-1097 (auth-tls-match-cn Annotation Injection): Bypasses validation to inject arbitrary NGINX configurations
- CVE-2025-1098 (mirror UID Injection): Allows injecting arbitrary NGINX configuration directives
- CVE-2025-1974 (NGINX Configuration Code Execution): Allows loading arbitrary shared libraries during configuration validation
The Impact on Kubernetes Environments
Technical Analysis of the Vulnerabilities
CVE-2025-24514: auth-url Annotation Injection
metadata:
annotations:
nginx.ingress.kubernetes.io/auth-url:"http://valid-looking-url.com; load_module modules/ngx_http_js_module.so;"
CVE-2025-1097: auth-tls-match-cn Annotation Injection
This vulnerability allows attackers to bypass validation mechanisms and inject arbitrary NGINX configurations through the `nginx.ingress.kubernetes.io/auth-tls-match-cn` annotation.
CVE-2025-1098: mirror UID Injection
The vulnerability allows attackers to inject arbitrary NGINX configuration directives through the `nginx.ingress.kubernetes.io/mirror-uid` annotation, which is designed to specify which user ID should be used for mirroring traffic.
CVE-2025-1974: NGINX Configuration Code Execution
This vulnerability allows attackers to load arbitrary shared libraries during NGINX configuration validation, potentially leading to remote code execution. The issue arises from the way NGINX processes and validates configurations.
Recommended Actions for IngressNightmare Mitigatio
- Update Ingress NGINX Controller: Upgrade to version 1.12.1, 1.11.5, or later depending on your Kubernetes version
- Implement Network Policies: Ensure the admission webhook endpoint is not exposed externally and that only the Kubernetes API Server can access the admission controller
- Monitor for Exploitation: Implement logging and monitoring to detect potential exploitation attempts
- Review Ingress Definitions: Audit all ingress definitions in your clusters to identify potentially malicious annotations
- Verify Remediation: After updating, verify that your Ingress NGINX Controller is properly patched and that no exploitation has occurred
Temporary Mitigations
If immediate updates are not possible, consider these temporary measures:
- Disable Validation Webhook: Temporarily disable the validation webhook to prevent exploitation through the admission controller
- Restrict Access: Implement strict network policies to limit access to the Ingress NGINX Controller
- Regular Auditing: Frequently audit ingress resources for suspicious annotations
- Implement WAF: Consider deploying a Web Application Firewall in front of your cluster to filter malicious requests