Quite some #IngressNightmare #CVE-2025-1974 PoCs on GitHub now that look good at a cursory review:

https://github.com/hakaioffsec/IngressNightmare-PoC

https://github.com/yoshino-s/CVE-2025-1974/

https://github.com/Esonhugh/ingressNightmare-CVE-2025-1974-exps/

https://github.com/hi-unc1e/CVE-2025-1974-poc/

https://github.com/lufeirider/IngressNightmare-PoC

https://github.com/zwxxb/CVE-2025-1974

https://github.com/rjhaikal/POC-IngressNightmare-CVE-2025-1974

Quick note on exploits trying to use `nginx.ingress.kubernetes.io/server-snippet`: That annotation has been identified as an issue before and has been disabled to mitigate CVE-2021-25742.

After my last post analyzing the NGINX #IngressNightmare vulnerability, I’m excited to share a new addition to my Kubernetes Security: Advanced Exploitation series!

Inspired by the excellent research from the Wiz team on CVE-2025-1974, I’ve created a hands-on lab that walks you through exploiting this issue step by step. You can try it out here:
https://github.com/Alevsk/dvka/tree/master/workshop/labs/ingress-nightmare

This lab offers a safe environment to:

1. Reproduce the vulnerability
2. Understand how the exploit works
https://github.com/Alevsk/dvka/blob/master/workshop/labs/ingress-nightmare/cve-2025-1974.py
3. Generate your own indicators of compromise (IOCs)

It’s a great way to deepen your Kubernetes security knowledge and gain hands-on experience with real-world exploitation techniques. Have fun learning, and feel free to share any thoughts or questions!

'... series of unauthenticated ... [RCE] vulnerabilities in Ingress NGINX Controller for Kubernetes dubbed #IngressNightmare ...

'... 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’ admission controllers to the public internet ...

'Using Ingress-NGINX is one of the most common methods for exposing Kubernetes applications externally.

'Our research show that over 41% of internet-facing clusters are running Ingress-NGINX'.
https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities

This Week in Security: IngressNightmare, NextJS, and Leaking DNA - This week, researchers from Wiz Research released a series of vulnerabilities in t... - https://hackaday.com/2025/03/28/this-week-in-security-ingressnightmare-nextjs-and-leaking-dna/ #thisweekinsecurity #ingressnightmare #hackadaycolumns #securityhacks #23andme #nextjs #news

I wrote up some details on exploiting #IngressNightmare #CVE-2025-1974:
www.averlon.ai/blog/kuberne...

Where are we at with releasing a full PoC?

This week a critical security vulnerability in #Kubernetes, dubbed "#IngressNightmare", was published.

As we are using #Rancher managed Kubernetes clusters ourselves, we share our analysis in our latest #blog post.

How Rancher RKE clusters are affected, how the #vulnerability can be mitigated and when a fix can be expected.

https://www.infiniroot.com/blog/1478/kubernetes-vulnerability-ingressnightmare-rancher-clusters-affected

Attention all k8s people: There's an #IngressNightmare in progress.
> "Based 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’ admission controllers to the public internet—putting them at immediate critical risk."
https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities

Why VSHN Managed OpenShift Customers Are Safe from the Recent Ingress NGINX Vulnerability. Read our blog post: https://buff.ly/Z0qXYP6 #IngressNightmare #NGINX #Kubernetes #Ingress #IngressNGINXController #OpenShift #ManagedOpenShift

#NGINX Critical Ingress NGINX Controller for #Kubernetes Vulnerability Allows #RCE Without Authentication. A set of 5 critical security CVE with CVSS scores 4.8-9.8 affecting ~43% of cloud environments globally:

#IngressNightmare

https://thehackernews.com/2025/03/critical-ingress-nginx-controller.html

#IngressNightmare: Wiz Research uncovers a critical vulnerability in Ingress-NGINX

Wiz Research found a novel attack vector in one of Kubernetes's most fundamental projects, Ingress-NGINX, which is rated CVSS 9.8.

Why does this matter?
Ingress-NGINX is found in over 40% of cloud environments. If you're using this project, your infrastructure could be at risk.

What's at risk?
This vulnerability allows attackers to gain access to all secrets across all namespaces in a Kubernetes cluster — essentially enabling a cluster takeover.

What should you do?
A patch is available.
Upgrade to version v1.12.1, v1.11.5 to protect your environment.

Wiz research has worked closely with the Kubernetes maintainers over the last couple of months to mitigate this attack surface fully

For full technical details and a remediation guide, check out our blog:

If you're running RKE2 and want to mitigate #IngressNightmare at least until a patch is released, you can do something like the gist below. Note, I would test this thoroughly first.

https://gist.github.com/flrichar/69dc98ba6d683b63fb9ce65c4a31a257

Multiple CVEs tied to admission controller component of Ingress NGINX Controller. In a nutshell the problem is:

"[...] a vulnerability in this phase that allows injecting an arbitrary NGINX configuration remotely, by sending a malicious ingress object directly to the admission controller through the network."

"[...]Exploitation of these vulnerabilities leads to unauthorized access to all secrets stored across all namespaces in the Kubernetes cluster by attackers, which can result in cluster takeover.[...]"

writeup: https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities

Mitigation:

Patch or ... "Ensure the admission webhook endpoint is not exposed externally"

Nuclei Template for detection of admission controller: https://gist.github.com/nirohfeld/7a7c82c62321de9c2ef95d266b241fcb

So, today are you more of a #ingressnightmare or #signalgate person?

Fiksene for CVE-ene involvert i #ingressnightmare er jo også litt interessante:

* CVE-2025-1097 mer quoting:
https://github.com/kubernetes/ingress-nginx/pull/13068/commits/06c992abd8eef9710359a236c443c613d29fdfad

* CVE-2025-1098 mer & flyttet quoting:
https://github.com/kubernetes/ingress-nginx/pull/13068/commits/2e9f37380afb7853fa6daa1c3e6659550aadfd90

* CVE-2025-1974 diverse utkommentert kode, tydeligvis tester?:
https://github.com/kubernetes/ingress-nginx/pull/13068/commits/0ccf4caaadec919680c455d221e53d97970d527d

* CVE-2025-24513 bruke en ordentlig filepath-type:
https://github.com/kubernetes/ingress-nginx/pull/13068/commits/cbc159094f6d1b1bf8cf1761eb119138d1f95df1

* CVE-2025-24514 mer sitering:
https://github.com/kubernetes/ingress-nginx/pull/13068/commits/ab470eb920924d62a197ebddd8a4cc3031a77ddf

Seeing the nginx ingress controller security issue I guess Today We will have a busy day #IngressNightmare

I spent some time diving into the details of the recent NGINX (ingress-nginx) exploit publication — #IngressNightmare — and here’s a simplified breakdown I put together:

TL;DR:
This attack targets NGINX by tricking it into executing a malicious configuration that leverages dangerous directives (like ssl_engine) to take over the Kubernetes Pod and escalate privileges.

First things first, the attacker needs to be inside the Kubernetes perimeter and able to communicate with the ingress-nginx-controller Pod. This is more common than you’d think — many clusters are deployed without any network segmentation policies in place.

From there, the attack unfolds in two phases:
1. Upload a malicious module to the file system of the ingress-nginx-controller Pod.
2. Send a configuration to ingress-nginx that uses the ssl_engine directive to load that malicious module.

The brilliance of this attack lies in the details. Let me walk you through how it works:

In the first step, the attacker exploits a feature called Client Body Buffers. When an HTTP request exceeds 8KB, NGINX starts writing the body to disk instead of keeping it in memory. To ensure the malicious module is properly staged for the next step, the attacker sets a Content-Length header that leaves the server “waiting” for more data.

Then comes phase two: the attacker floods the ingress-nginx-controller with requests containing an AdmissionReview that includes a config using ssl_engine, pointing to the malicious module injected earlier (e.g., /proc/$PID/fd/$FD). Since the attacker doesn’t know the exact process ID or file descriptor, they brute-force it. But because containerized environments typically have very few processes, this brute-force step is trivial.

Once the attacker guesses the correct combination, NGINX loads the malicious module — and just like that, command execution is achieved.

From that point on, the attacker can use the container’s service account token to read secrets, access config files, move laterally, and ultimately take control of the entire cluster.

https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities

https://forum.chatons.org/t/critical-ingress-nginx-vulnerability-for-kubernetes/7171/1

#IngressNightmare #kubernetes #ingress_nginx #CVE-2025-24514 #CVE-2025-1097 #CVE-2025-1098 CVE-2025-1974 #cvss9.8