As more organizations adopt containerization, Kubernetes adoption is at an all-time high. A key component of 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’s power and complexity lend themselves to a considerable risk profile when compromised.
In this report, Sentinel Labs discusses a grouping of critical vulnerabilities dubbed IngressNightmare and shares actionable mitigation and detection strategies.
Beyond this specific security risk, given the understanding of challenges in Ingress, it is crucial to maintain 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 essential in maintaining a resilient Kubernetes environment.
What is Ingress? In Kubernetes, Ingress is a traffic manager that routes 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
Example YAML of Ingress resource routing rules
Using the above example, below is a Kubernetes architecture diagram showcasing Ingress routing traffic to specific services:
Flow of external traffic to internal services via the ingress controller within the cluster
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 before v1.11.0
Versions v1.11.0 through v1.11.4Version v1.12.0
Stages of IngressNightmare | How the Attack Works - IngressNightmare exploits weaknesses in Kubernetes Ingress NGNIX by leveraging misconfigurations and unauthorized access points. This multi-stage attack starts with identifying vulnerable clusters and ends with an attacker gaining complete control over them. Let’s briefly outline the stages of this attack:
- Discovery & Targeting—Attackers scan for clusters using Ingress NGINX, often those with publicly exposed admission controllers. The adversary is seeking vulnerable targets that are susceptible to this attack.
- Crafting Malicious Ingress Object—Once found, a specially crafted ingress object containing injected malicious NGINX configurations is created.
- Sending Malicious Request—The malicious object is sent to the admission controller as an unauthenticated Admission Review request.
- NGINX Configuration Generation—The controller generates an NGINX configuration from the ingress object. In this configuration, injected directives are incorporated.
- NGINX Configuration Validation (Exploitation) – When the controller validates the configuration using nginx -t, the injected code is executed, resulting in RCE.
Gaining Access & Privilege Escalation—With the controller’s elevated privileges, attackers can access all cluster secrets and can move laterally, eventually taking over the cluster.
Ingress Nightmare Attack
Validation & Mitigation - Our recommendation is first to 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 leverage Ingress NGINX Controller and are on a vulnerable version, we recommend the following.
Immediate Action - 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.
Fixing the code that allows reading of all cluster secrets
If it isn’t possible to update, there are temporary mitigations available.
Temporary Mitigations –
- Restrict Access – Enforce strict network policies so 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 Protect Kubernetes - There are several 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 highly likely given the nature of Ingress), and maps the affected resources. Additionally, SentinelOne can 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 is 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), such as its Kubernetes Security Posture Management (KSPM) and Offensive Security Engine features.
KSPM helps protect Kubernetes Clusters by identifying misconfigurations and vulnerabilities that may go unnoticed. Below is a screenshot of one of CNS’s KSPM policies that hunts for this specific vulnerability:
The KSPM Policy: Potential Ingress Nightmare vulnerability found inside the Kubernetes Cluster
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:
Offensive Security Engine alert for proven Kubernetes clusters at risk from IngressNightmare
Let's shift focus from proactive to reactive security and take a passive to an 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.
A malicious process stemming from the NGINX Ingress Controller is detected.
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:
A malicious process stemming from the NGINX Ingress Controller is detected
Hunting Queries—Finally, for SentinelOne customers looking to proactively hunt for potential exploitation of IngressNightmare, Sentinel recommends checking for anomalies such as Behavioral Indicators 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 following query can help provide a starting point for hunting and reviewing 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:
Verify Secret and Certificate Presence: Kubectl describes the secret in your-tls-secret—n your-namespace. Ensure both tls.crt and tls.key are correctly set.
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
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:
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
Test with Curl: curl -v https://example.com/api. Analyze the verbose output to track where the request is routed.
Log Inspection:
kubectl logs -l app.kubernetes.io/name=ingress-nginx -n ingress-nginx
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:
For NGINX Controllers:
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
nginx.ingress.kubernetes.io/ssl-redirect: "true"
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:
Monitor Resource Usage: kubectl top pod -n ingress-nginx
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"
Scale Horizontally: Increase replicas if necessary.
kubectl scale deployment ingress-nginx-controller -n ingress-nginx --replicas=3
Conclusion—Securing Kubernetes clusters demands a multifaceted approach, including 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. However, the operational challenges of ingress often require robust troubleshooting practices to ensure smoother operation. You can safeguard your Kubernetes environment and maintain reliable service delivery by combining rigorous security measures with detailed diagnostics.
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.
This article is shared at no charge and is for educational and informational purposes only.
Red Sky Alliance is a Cyber Threat Analysis and Intelligence Service organization. We provide indicators of compromise information via a notification service (RedXray) or an analysis service (CTAC). For questions, comments, or assistance, please get in touch with the office directly at 1-844-492-7225 or feedback@redskyalliance.com
• Reporting: https://www.redskyalliance.org/
• Website: https://www.redskyalliance.com/
• LinkedIn: https://www.linkedin.com/company/64265941
Weekly Cyber Intelligence Briefings:
REDSHORTS - Weekly Cyber Intelligence Briefings
https://register.gotowebinar.com/register/5207428251321676122
© 2025 Red Sky Alliance Corporation. All rights reserved
Comments