“IngressNightmare” Critical RCE Vulnerabilities in Kubernetes NGINX Clusters Let Attackers Gain Full Control

A recently discovered set of vulnerabilities, dubbed “IngressNightmare,” found in Ingress NGINX Controller, exposing clusters to unauthenticated remote code execution (RCE). Kubernetes dominates container orchestration, but its prominence has made it a target for exploitation.

In Kubernetes, Ingress serves as a sophisticated traffic management system, enabling external access to internal services. It comprises two core components:

• Ingress Resources: These define routing rules based on hostnames, paths, or other criteria, typically specified in YAML configuration files.
• Ingress Controllers: These implement the routing rules, often using a reverse proxy or load balancer.

The Ingress NGINX Controller, built on the popular NGINX web server, is one of the most widely deployed options, boasting over 18,000 stars on GitHub.

These flaws could allow attackers to compromise entire Kubernetes environments. Ingress in Kubernetes manages external traffic to internal services through Ingress resources YAML files defining routing rules by hostname or path and an Ingress Controller, such as the NGINX variant, which enforces these rules via a reverse proxy.

For example, a YAML might direct example.com/ to a frontend service and example.com/api to a backend service. While versatile, this system is vulnerable when exploited.

IngressNightmare: Four Critical Vulnerabilities

IngressNightmare encompasses four vulnerabilities in the Ingress NGINX Controller’s admission webhook, which validates Ingress objects. These flaws affect versions prior to v1.11.0, v1.11.0–v1.11.4, and v1.12.0, with patches available in v1.11.5 and v1.12.1. They are:

• CVE-2025-1097 (Auth-tls-match-cn Annotation Injection): This vulnerability allows attackers to inject malicious configurations via the auth-tls-match-cn annotation, bypassing authentication checks. It can manipulate TLS verification, potentially exposing sensitive data or enabling further exploitation (CVSS 8.8).
• CVE-2025-1098 (Mirror UID Injection): By exploiting mirror-related annotations (mirror-target or mirror-host) or UID manipulation, attackers can inject arbitrary configurations. This could redirect traffic or execute unauthorized actions, compromising cluster integrity (CVSS 8.8).
• CVE-2025-24514 (Auth-url Annotation Injection): This flaw targets the auth-url annotation, permitting attackers to inject malicious URLs that the controller processes. It can lead to unauthorized access or serve as an entry point for broader attacks (CVSS 8.8).
• CVE-2025-1974 (NGINX Configuration Code Execution): The most severe, this vulnerability enables unauthenticated RCE by exploiting NGINX configuration validation. Attackers inject code executed during the nginx -t test, granting access to cluster secrets and full control (CVSS 9.8).

Successful exploitation could expose all secrets, enable lateral movement, or result in cluster takeover.

How the Attack Works?

The IngressNightmare attack exploits these weaknesses in a multi-stage process. It starts with discovery, where attackers scan for exposed controllers using tools like Shodan.

They then craft a malicious Ingress object, embedding harmful NGINX directives into annotations like auth-url or auth-tls-match-cn.

This object is sent as an unauthenticated AdmissionReview request to the webhook, exploiting its lack of authentication.

According to the report, The controller generates an NGINX configuration incorporating the injected code, and during validation with nginx -t, the malicious directives such as loading a rogue library execute, achieving RCE. With the controller’s privileges, attackers access secrets, move laterally, and potentially dominate the cluster.

Mitigation Strategies

Check for vulnerable pods with:

bash

kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx

Verify versions via kubectl describe pod. If at risk, upgrade to v1.11.5 or v1.12.1 using:

bash

helm upgrade ingress-nginx ingress-nginx/ingress-nginx --version 

If patching isn’t immediate, restrict webhook access with network policies or disable it by setting controller.admissionWebhooks.enabled=false (Helm) or removing the ValidatingWebhookConfiguration.

Ingress also poses operational issues: SSL errors need secret and DNS validation; routing problems require log and endpoint checks; and performance bottlenecks benefit from scaling replicas and adjusting proxy settings like proxy-buffer-size: “8k”.

IngressNightmare reveals Kubernetes’ exposure to sophisticated attacks. With patches and mitigation steps available, organizations must prioritize securing their clusters. Operational diligence ensures resilience. Act now to counter this critical threat.

Find this News Interesting! Follow us on Google News, LinkedIn, and X to Get Instant Updates