{"id":2504,"date":"2025-03-26T01:06:15","date_gmt":"2025-03-26T01:06:15","guid":{"rendered":"https:\/\/cybersecurityinfocus.com\/?p=2504"},"modified":"2025-03-26T01:06:15","modified_gmt":"2025-03-26T01:06:15","slug":"critical-rce-flaws-put-kubernetes-clusters-at-risk-of-takeover","status":"publish","type":"post","link":"https:\/\/cybersecurityinfocus.com\/?p=2504","title":{"rendered":"Critical RCE flaws put Kubernetes clusters at risk of takeover"},"content":{"rendered":"
\n
\n
\n
\n
<\/div>\n

The Kubernetes project has released patches for five vulnerabilities in a widely used popular component called the Ingress NGINX Controller that\u2019s used to route external traffic to Kubernetes services. If exploited, the flaw could allow attackers to completely take over entire clusters.<\/p>\n

\u201cBased on our analysis, about 43% of cloud environments are vulnerable to these vulnerabilities, with our research uncovering over 6,500 clusters, including Fortune 500 companies, that publicly expose vulnerable Kubernetes ingress controllers\u2019 admission controllers to the public internet \u2014 putting them at immediate critical risk,\u201d wrote researchers from cloud security firm Wiz<\/a> who found and reported the flaws<\/a>.<\/p>\n

Collectively dubbed IngressNightmare by the Wiz research team, the vulnerabilities are tracked as CVE-2025-1097, CVE-2025-1098, CVE-2025-24514 and CVE-2025-1974. They were fixed in versions 1.12.1 and 1.11.5 of Ingress NGINX Controller<\/a> (Ingress-NGINX) released on Monday. A fifth flaw, tracked as CVE-2025-24513, was also identified and patched in these releases.<\/p>\n

Unauthenticated ingress configuration injection<\/h2>\n

Kubernetes is the most popular container orchestration system that\u2019s used to automate the deployment of applications in cloud environments by splitting them into networks of microservices that run independently inside their own secure containers or group of containers called pods.<\/p>\n

One of the Kubernetes features that allows exposing workloads to the internet is called ingress<\/a> and allows admins to route incoming traffic to different backend services based on rules that are defined through the Kubernetes API.<\/p>\n

There are multiple ingress controllers available, but Ingress-NGINX which leverages the NGINX web server and reverse proxy, is one of the most popular ones and commonly used as an example in official documentation. According to Wiz, over 41% of internet-facing Kubernetes clusters are running Ingress-NGINX.<\/p>\n

The admission controller<\/a> in Ingress-NGINX is used to process incoming ingress objects, create matching NGINX configurations based on them and then validate them and use them to decide how and where to route requests. The vulnerabilities found by Wiz allow an attacker to inject configuration parameters, which when validated, cause the NGINX validator to execute arbitrary code.<\/p>\n

\u201cProper handling of these NGINX configuration parameters is crucial, because Ingress-NGINX needs to allow users significant flexibility while preventing them from accidentally or intentionally tricking NGINX into doing things it shouldn\u2019t,\u201d the Kubernetes team said in a blog post<\/a>.<\/p>\n

The problem is that the Ingress-NGINX pod has elevated privileges and unrestricted network accessibility by design. More importantly it has access to all Secrets cluster-wide by default, meaning that an attacker with code execution action in this pod can leak those secrets and take over the entire cluster.<\/p>\n

The CVE-2025-1974 vulnerability is the most serious and is rated with a severity score of 9.8 on the CVSS scale. It allows anyone with access to the Pod network to exploit the other configuration injection vulnerabilities, which would otherwise require privileged actions to exploit.<\/p>\n

\u201cWhen combined with today\u2019s other vulnerabilities, CVE-2025-1974 means that anything on the Pod network has a good chance of taking over your Kubernetes cluster, with no credentials or administrative access required,\u201d the Kubernetes maintainers warned. \u201cIn many common scenarios, the Pod network is accessible to all workloads in your cloud VPC, or even anyone connected to your corporate network! This is a very serious situation.\u201d<\/p>\n

Two ways to mitigate the flaws<\/strong><\/h2>\n

The best fix is to upgrade the Ingress-NGINX component to one of the patched versions. Admins can determine if it\u2019s being used inside their clusters by typing: kubectl get pods \u2013all-namespaces \u2013selector app.kubernetes.io\/name=ingress-nginx<\/p>\n

In situations where an immediate version upgrade is not possible, admins can reduce risk by deleting the ValidatingWebhookConfiguration called ingress-nginx-admission and remove the \u2013validating-webhook argument from the ingress-nginx-controller container\u2019s Deployment or DaemonSet. If ingress-nginx was installed using Helm, it can be reinstalled with controller.admissionWebhooks.enabled=false.<\/p>\n

This will mitigate CVE-2025-1974 in particular, which makes it much easier to exploit the other vulnerabilities without authentication. However, the Validating Admission Controller should not remain disabled for a long time because it provides safeguards against bad ingress configurations to legitimate users.<\/p>\n

Related reading: How to strengthen your Kubernetes defenses<\/a><\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"

The Kubernetes project has released patches for five vulnerabilities in a widely used popular component called the Ingress NGINX Controller that\u2019s used to route external traffic to Kubernetes services. If exploited, the flaw could allow attackers to completely take over entire clusters. \u201cBased on our analysis, about 43% of cloud environments are vulnerable to these […]<\/p>\n","protected":false},"author":0,"featured_media":2484,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-2504","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-education"],"_links":{"self":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/2504"}],"collection":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=2504"}],"version-history":[{"count":0,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/2504\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/media\/2484"}],"wp:attachment":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=2504"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=2504"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=2504"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}