IngressNightmare: Analysis of Critical Vulnerabilities in Kubernetes Ingress NGINX Controller

Executive Summary

On March 24, 2025, Wiz Research disclosed a series of critical vulnerabilities in Ingress NGINX Controller for Kubernetes, collectively dubbed #IngressNightmare:

• CVE-2025-1097: Auth-TLS-Match-CN Annotation Injection
• CVE-2025-1098: Mirror UID Injection
• CVE-2025-24514: Auth-URL Annotation Injection
• CVE-2025-1974: NGINX Configuration Code Execution

These unauthenticated Remote Code Execution (RCE) vulnerabilities have been assigned a CVSS base score of 9.8. According to Wiz Research, exploitation allows attackers to gain unauthorized access to all secrets across all namespaces in affected Kubernetes clusters, potentially leading to complete cluster takeover.

Wiz’s analysis indicates approximately 43% of cloud environments are vulnerable, with over 6,500 clusters (including Fortune 500 companies) publicly exposing vulnerable Kubernetes ingress controllers’ admission controllers to the internet. Our security team has conducted an independent assessment of these vulnerabilities, and we believe this represents a significant risk to organizations using Kubernetes.

What is Ingress NGINX Controller?

Ingress NGINX Controller is one of the most popular ingress controllers for Kubernetes, with over 18,000 stars on GitHub. As a core Kubernetes project, it’s explicitly highlighted in the Kubernetes documentation as an example Ingress controller that fulfills the prerequisite for using Ingress in Kubernetes.

Its primary function is to accept incoming traffic and route it to the relevant Kubernetes Services, which then forward the traffic to the appropriate Pods based on defined rules. Specifically, Ingress NGINX Controller is built on top of the popular NGINX reverse proxy.

According to Wiz’s research, over 41% of internet-facing clusters run Ingress-NGINX, making this vulnerability particularly concerning due to its widespread deployment.

Technical Analysis: The Vulnerabilities

The Vulnerable Component: Admission Controller

At the heart of these vulnerabilities is the admission controller component of Ingress NGINX. This controller validates incoming ingress objects before they are deployed. By default, these admission controllers are accessible over the network without authentication, making them highly appealing attack vectors.

When the Ingress-NGINX admission controller processes an incoming ingress object, it:

1. Constructs an NGINX configuration from the ingress object
2. Validates this configuration using the NGINX binary

The vulnerabilities exist in this validation process.

CVE-2025-1974: Configuration Validation RCE

The most severe vulnerability in the chain exists in how the admission controller validates NGINX configurations. When processing an incoming ingress object, the controller constructs a temporary NGINX configuration and then runs the NGINX binary with the -t flag to validate it.

// testTemplate checks if the NGINX configuration inside the byte array is valid
// running the command "nginx -t" using a temporal file.
func (n *NGINXController) testTemplate(cfg []byte) error {
    ...
    tmpfile, err := os.CreateTemp(filepath.Join(os.TempDir(), "nginx"), tempNginxPattern)
    ...
    err = os.WriteFile(tmpfile.Name(), cfg, file.ReadWriteByUser)
    ...
    out, err := n.command.Test(tmpfile.Name())

func (nc NginxCommand) Test(cfg string) ([]byte, error) {
    //nolint:gosec // Ignore G204 error
    return exec.Command(nc.Binary, "-c", cfg, "-t").CombinedOutput()
}

This validation process was not properly sandboxed. As a result, an attacker could craft a malicious ingress object that, when processed, would generate an NGINX configuration containing code that would be executed during the validation phase.

To address this vulnerability, the Kubernetes team completely removed the NGINX configuration validation step during admission control:

/* Deactivated to mitigate CVE-2025-1974
// TODO: Implement sandboxing so this test can be done safely
err = n.testTemplate(content)
if err != nil {
    n.metricCollector.IncCheckErrorCount(ing.ObjectMeta.Namespace, ing.Name)
    return err
}
*/

Template Injection Vulnerabilities (CVE-2025-1097, CVE-2025-1098, CVE-2025-24514)

The other three CVEs relate to template injection vulnerabilities in the NGINX configuration template. These vulnerabilities allowed attackers to inject malicious content into the NGINX configuration through various annotations.

CVE-2025-24514: Auth-URL Annotation Injection

The authreq parser is responsible for handling authentication-related annotations. When the temporary configuration is created, $externalAuth.URL (which corresponds to the URL from the auth-url annotation) is incorporated without proper sanitization:

proxy_http_version 1.1;
proxy_set_header Connection "";
set $target {{ changeHostPort $externalAuth.URL $authUpstreamName }};
{{ else }}
proxy_http_version {{ $location.Proxy.ProxyHTTPVersion }};
set $target {{ $externalAuth.URL }};
{{ end }}

This lack of proper sanitization allows an attacker to inject arbitrary NGINX configuration directives. The patch added proper quoting:

- set $target {{ $externalAuth.URL }};
+ set $target {{ $externalAuth.URL | quote }};

CVE-2025-1097: Auth-TLS-Match-CN Annotation Injection

The auth-tls-match-cn annotation requires:

1. The value must start with CN=
2. All remaining characters must form a valid regular expression

While these requirements seem restrictive, Wiz researchers discovered techniques to bypass both requirements and inject arbitrary NGINX configurations. The fix implemented proper quoting:

- if ( $ssl_client_s_dn !~ {{ $server.CertificateAuth.MatchCN }} ) {
+ if ( $ssl_client_s_dn !~ {{ $server.CertificateAuth.MatchCN | quote }} ) {

CVE-2025-1098: Mirror UID Injection

In the mirror annotation parser, the code processes the UID from the ingress object and inserts it into $location.Mirror.Source in the temporary NGINX configuration. Since this injection is in the UID parameter (which is not a Kubernetes annotation), the input does not get sanitized by the annotations’ regex rules.

The patch added proper quoting:

- mirror {{ $location.Mirror.Source }};
+ mirror {{ $location.Mirror.Source | quote }};

From Injection to Remote Code Execution

Wiz researchers demonstrated how these injection vulnerabilities could be leveraged to achieve Remote Code Execution. The key insight was discovering that the ssl_engine directive, part of the OpenSSL module, can load shared libraries—an undocumented behavior. Unlike other directives like load_module, the ssl_engine directive can be used at any point within the configuration file.

The attack chain Wiz documented works as follows:

1. Upload a payload in the form of a shared library to the pod by abusing the client-body buffer feature of NGINX
2. Send an AdmissionReview request to the admission controller, which contains a directive injection
3. The injected directive (ssl_engine) causes NGINX to load the specified file as a shared library
4. The shared library is loaded, executing code remotely

This creative attack chain demonstrates the severity of these vulnerabilities when chained together.

Impact Assessment and Mitigation

Impact

These vulnerabilities have a severe impact due to:

• No authentication required for exploitation
• Remote exploitation possible
• Ability to execute arbitrary code
• Access to all secrets across all namespaces
• Potential for complete cluster takeover

Recommended Mitigation Strategies

Update to Fixed Versions

The most effective mitigation is to update to patched versions:

• Ingress NGINX Controller version 1.12.1
• Ingress NGINX Controller version 1.11.5

If Immediate Updating is Not Possible

Consider these alternative mitigations recommended by Wiz and the Kubernetes security team:

1. Enforce strict network policies so only the Kubernetes API Server can access the admission controller
2. Temporarily disable the admission controller component:
   • If installed using Helm, reinstall with controller.admissionWebhooks.enabled=false
   • If installed manually, delete the ValidatingWebhookConfiguration called ingress-nginx-admission and remove the --validating-webhook argument from the ingress-nginx-controller container’s Deployment or DaemonSet

Remember to re-enable the Validating Admission Controller after you upgrade, as it provides important safeguards for your Ingress configurations.

Responsible Disclosure Timeline

The Wiz Research team followed responsible disclosure practices:

• December 31, 2024 – Initial report of CVE-2025-1974 and CVE-2025-24514
• January 2, 2025 – Report of CVE-2025-1097
• January 3-21, 2025 – Multiple fix proposals and bypass discoveries
• February 7, 2025 – Internal patches for the injection vulnerabilities
• February 20, 2025 – Removal of NGINX configuration validation
• March 10, 2025 – Embargo notifications sent
• March 24, 2025 – Public disclosure

Our Analysis and Recommendations

Based on our independent review of the disclosed vulnerabilities, we assess that IngressNightmare represents a critical security risk for organizations using Kubernetes with Ingress NGINX Controller. The attack surface—an unauthenticated admission controller with access to cluster secrets—is particularly concerning.

We recommend organizations take the following steps:

1. Immediate Inventory: Identify all clusters running Ingress NGINX Controller and determine if they are vulnerable versions
2. Prioritize Updates: Deploy patched versions in production environments as soon as possible
3. Network Controls: Review network policies and ensure strict access controls to admission controllers
4. Defense in Depth: Implement additional security monitoring for unexpected API server activity
5. Threat Hunting: Search for signs of exploitation in vulnerable environments

The IngressNightmare vulnerabilities highlight two important lessons for Kubernetes security:

1. Admission controllers represent a significant and often overlooked attack surface
2. The practice of running validation code on untrusted input without proper sandboxing can lead to critical vulnerabilities

Organizations should review their Kubernetes security posture holistically, particularly focusing on components that process external input or have elevated privileges.

Conclusion

The IngressNightmare vulnerabilities discovered by Wiz Research emphasize the importance of securing every component in complex systems like Kubernetes. Even internal components not directly exposed to the internet can become attack vectors if they process untrusted input.

We commend the Kubernetes security team and the Ingress-NGINX maintainers for their prompt response and comprehensive fixes to these critical vulnerabilities. Their work highlights the strength of the open-source security model and responsible disclosure process.

Organizations using Kubernetes should prioritize patching these vulnerabilities and implementing security best practices to protect their containerized environments.