IngressNightmare | Critical Unauthenticated RCE Vulnerabilities in Kubernetes Ingress NGINX

As more organizations adopt containerization, Kubernetes adoption is at an all-time high. A key component to any Kubernetes cluster is allowing and managing external traffic to the services organizations are building. Enter, Ingress. As a powerful component and set of resources that expose services to the outside world, Ingress’ power and complexity lends itself to a considerable risk profile when compromised.

In this post, we dive into a grouping of critical vulnerabilities dubbed IngressNightmare and share actionable mitigation and detection strategies, including multiple ways in which SentinelOne’s Singularity Platform can highlight both IngressNightmare vulnerability exposure and possible exploitation in runtime.

Beyond this specific security risk, given understanding challenges in Ingress is crucial to maintaining a resilient Kubernetes environment, this post additionally contains troubleshooting tips to tackle common Ingress issues like SSL misconfigurations, routing anomalies, and performance bottlenecks. Understanding and overcoming these challenges is important in maintaining a resilient Kubernetes environment.

What is Ingress?

In Kubernetes, Ingress acts as a traffic manager, routing external access to services within your cluster. Ingress is composed of two key components: Ingress resources that define routing rules based on hostnames and paths, and an Ingress Controller (like the Ingress NGINX Controller) that implements these rules, typically by configuring a load balancer or reverse proxy (in this case, NGINX).

Below is an example of a YAML file wherein the Ingress resource defines the following routing rules:

• example.com/ → frontend-service
• example.com/api → backend-service

Using the above example, below is a Kubernetes architecture diagram showcasing Ingress routing traffic to specific services:

What Is IngressNightmare?

A series of critical security vulnerabilities, collectively known as IngressNightmare, have been discovered in the Ingress NGINX Controller for Kubernetes. These flaws, CVE-2025-1097, CVE-2025-1098, CVE-2025-24514, and the most severe, CVE-2025-1974, allow unauthenticated remote code execution (RCE) via the controller’s admission webhook, potentially enabling attackers to access all secrets across namespaces and take over entire clusters. CVE-2025-1974 is assigned a CVSS v3.1 base score of 9.8, making it a critical vulnerability in the context of the ingress-nginx controller.

These Ingress NGINX Controller vulnerabilities are tracked respectively as:

• 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

Successful exploitation of these vulnerabilities can result in:

• Unauthorized access to all Kubernetes Secrets across namespaces within a cluster,
• Lateral movement within the cluster, and even
• Complete cluster takeover by the adversary.

Affected Ingress NGINX Controller Versions:

• All versions prior to v1.11.0
• Versions v1.11.0 through v1.11.4Version v1.12.0

Stages of IngressNightmare | How the Attack Works

IngressNightmare works by exploiting weaknesses in Kubernetes Ingress NGNIX by leveraging misconfigurations and unauthorized access points. This is a multi-stage attack that starts with identifying vulnerable clusters and ends with an attacker gaining full control over them. Let’s briefly outline the stages of this attack:

1. Discovery & Targeting – Attackers scan for clusters using Ingress NGINX, often those with publicly exposed admission controllers. The adversary is seeking vulnerable targets susceptible to this attack.
2. Crafting Malicious Ingress Object – Once found, a specially crafted ingress object is created, containing injected malicious NGINX configurations.
3. Sending Malicious Request – The malicious object is sent as an unauthenticated AdmissionReview request to the admission controller.
4. NGINX Configuration Generation – The controller generates an NGINX configuration from the ingress object. Here, injected directives are incorporated.
5. NGINX Configuration Validation (Exploitation) – When the controller validates the configuration using nginx -t, the injected code is executed, resulting in RCE.
6. Gaining Access & Privilege Escalation – With the controller’s elevated privileges, attackers access all cluster secrets and can move laterally, eventually taking over the cluster.

Validation & Mitigation

Our recommendation is to first establish whether or not your clusters are vulnerable to this attack. Run the following command to check for vulnerable installations:

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

If your clusters are leveraging Ingress NGINX Controller and on a vulnerable version, we recommend the following.

Immediate Action

• As always, the best way to avoid vulnerability exploitation is to update/patch. In this instance update out of the risk zone by patching your Ingress NGINX Controller to v1.11.5, v1.12.1, or a later version.

If it isn’t possible to update, there are temporary mitigations available.

Temporary Mitigations

• Restrict Access – Enforce strict network policies so that only the Kubernetes API Server can access the admission controller.
• Disable Admission Controller – Temporarily disable the admission controller component if you cannot upgrade immediately.

• • If using Helm – Reinstall with controller.admissionWebhooks.enabled=false.

• • If installed manually – Delete the ValidatingWebhookConfiguration named ingress-nginx-admission and remove the --validating-webhook argument from the controller’s Deployment or DaemonSet.

How SentinelOne Helps You To Protect Kubernetes

There are a number of ways in which SentinelOne keeps Kubernetes clusters safe. To focus on IngressNightmare as a specific threat, Singularity Platform identifies whether the vulnerabilities are present, validates if they are externally accessible (which is a high likelihood given the nature of ingress), and maps the affected resources. Additionally, SentinelOne is able to detect and respond to this attack as it unfolds, and has powerful capabilities to threat hunt potential adversary activity that would be seen post-exploit.

The range of detections are common for SentinelOne as we look to provide proactive alerts about your cluster health to help you reduce your exposures and attack surface as well as powerful reactive runtime defensive capabilities. The proactive capabilities are found within SentinelOne’s Cloud Native Security (CNS), and in this instance, its Kubernetes Security Posture Management (KSPM) and Offensive Security Engine features.

KSPM helps protect Kubernetes Clusters by identifying misconfigurations and vulnerabilities that may otherwise go unnoticed. Below is a screenshot of one of CNS’ KSPM policies that hunts for this specific vulnerability:

With its “attacker’s mindset” and scanning capabilities, the Offensive Security Engine goes a step further.  It establishes where the vulnerability is externally accessible and identifies the connected exposed assets vulnerable to IngressNightmare. Finally, because of the nature of the Offensive Security Engine, each alert is verified with evidence. Below is a screenshot of an alert prompted by the Offensive Security Engine:

As we shift our focus from proactive to reactive security, we go from a passive to active view of this threat and any potential exploitation. SentinelOne’s Cloud Workload Security agent, deployable via DaemonSet, provides runtime detection in both on-prem and cloud-managed Kubernetes clusters.  As adversaries look to leverage the IngressNightmare vulnerabilities to impact the cluster, for example via credential harvesting, the malicious processes are detected in real time.

Moving outside a process view, below is an example of Cloud Workload Security’s graphical view of affected assets and an alert for an adversary attempting a reverse shell post initial exploitation:

Hunting Queries

Finally, for SentinelOne customers looking to proactively hunt for potential exploitation of IngressNightmare, we recommend checking for anomalies such as Behavioral Indicators present in the ingress-nginx namespace.

event.type = 'Behavioral Indicators' and (k8sCluster.namespace='ingress-nginx' or k8sCluster.containerImage contains 'ingress-nginx/controller')

Customers can review destination IPs in outbound connections originating from Ingress Nginx to identify potentially compromised instances.

(k8sCluster.namespace='ingress-nginx' or k8sCluster.containerImage contains 'ingress-nginx/controller') event.type = 'IP Connect' event.network.direction='OUTGOING'

For instances of Ingress Nginx configured to use a namespace other than the default (ingress-nginx), the below query can help with a starting point for hunting and review of runtime activities.

dataSource.name = 'SentinelOne' and endpoint.os = 'linux' and tgt.process.name = 'nginx' and tgt.process.cmdline contains 'nginx-cfg' and tgt.process.cmdline contains ' -t'

Staying Ahead of Common Ingress Nightmares

Beyond IngressNightmare and other security vulnerabilities, Kubernetes Ingress can be challenging to manage in day-to-day operations. Here are some practical steps to diagnose and resolve frequent issues.

Nightmare #1: SSL Certificate Problems

Symptoms:

• Browser warnings: “Your connection is not secure”
• Inconsistent behavior between environments

Troubleshooting Steps:

1. Verify Secret and Certificate Presence: kubectl describe secret your-tls-secret -n your-namespace. Ensure both tls.crt and tls.key are correctly set.
2. Verify Ingress YAML:

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
   name: example-ingress
   annotations:
   nginx.ingress.kubernetes.io/ssl-redirect: "true"
   spec:
   tls:
   - hosts:
   - example.com
   secretName: your-tls-secret
   

3. DNS Verification: Ensure your DNS correctly resolves to your Ingress IP.

Nightmare #2: Routing Gone Wild

Symptoms:

• Random 404 errors
• Inconsistent routing behavior

Troubleshooting Steps:

1. Review Path Rules:

   rules:
   - host: example.com
   http:
   paths:
   - path: /api
   pathType: Prefix  # or Exact, based on your need
   backend:
   service:
   name: api-service
   port:
   number: 80
   

2. Test with Curl: curl -v https://example.com/api. Analyze the verbose output to track where the request is routed.
3. Log Inspection:

   kubectl logs -l app.kubernetes.io/name=ingress-nginx -n ingress-nginx

4. Verify Service Endpoints:

   kubectl get svc -n your-namespace
   kubectl get endpoints -n your-namespace

Nightmare #3: Annotation Confusion

Symptoms:

• Configurations seemingly not taking effect
• Unexpected redirects or behavior in staging versus production

Troubleshooting Steps:

1. For NGINX Controllers:

   annotations:
   nginx.ingress.kubernetes.io/rewrite-target: /
   nginx.ingress.kubernetes.io/ssl-redirect: "true"

2. For Traefik Controllers:

   annotations:
   traefik.ingress.kubernetes.io/redirect-entry-point: https

Tip! Always refer to the official documentation for your specific Ingress controller to ensure annotations are correctly applied.

Nightmare #4: Performance Bottlenecks

Symptoms:

• Slow loading times or timeouts during traffic peaks
• High CPU usage on Ingress controllers

Troubleshooting Steps:

1. Monitor Resource Usage: kubectl top pod -n ingress-nginx
2. Optimize Configuration:annotations:

   nginx.ingress.kubernetes.io/proxy-buffering: "on"
   nginx.ingress.kubernetes.io/proxy-buffer-size: "8k"
   nginx.ingress.kubernetes.io/proxy-body-size: "10m"

3. Scale Horizontally: Increase replicas if necessary.

   kubectl scale deployment ingress-nginx-controller -n ingress-nginx --replicas=3

Conclusion

Securing Kubernetes clusters demands a multi-faceted approach inclusive of both proactive and reactive strategies. Threats like IngressNightmare highlight the need to have continuous visibility of your Kubernetes exposures alongside runtime security, and as always underline the criticality of immediate patching. The operational challenges of ingress though often require robust troubleshooting practices to help ensure smoother operation. By combining rigorous security measures with detailed diagnostics, you can safeguard your Kubernetes environment and maintain reliable service delivery.

Call to Action:

• For Security – Upgrade your Ingress NGINX Controller immediately to v1.11.5, v1.12.1, or later.
• For Operations – Implement the troubleshooting steps provided, and consider adding visual aids (like flowcharts) to your team’s documentation for faster diagnosis.
• For customers of SentinelOne – Validate your risk to this threat via Cloud Native Security, and consider running quick hunts for post-exploitation activity.
• For Security Tooling – Should the tooling not be in place, consider investing in a Cloud Native Application Protection Platform (CNAPP) to secure Kubernetes and cloud environments.

For those seeking further information on how Singularity Cloud Security provides both proactive and reactive security for on-premise and cloud hosted Kubernetes clusters.

For a broader view of Kubernetes risks, our recent blog posts go into detail of the nature of Kubernetes Privilege Escalation specifically, and a walkthrough of how a chain of risks, much like IngressNightmare can lead to total cluster compromise.