Discover how Kubewarden can protect you from the critical #IngressNightmare vulnerability (CVE-2025-1974): https://www.kubewarden.io/blog/2025/04/ingress-nginx-cve-2025-1974/

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!

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

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

All you need to know on our latest discovery #IngressNightmare

In this episode of Crying Out Cloud, Amitai Cohen & Eden Naftali are joined by Nir Ohfeld — Head of Vulnerability Research at Wiz.

Nir and his team have uncovered some of the most impactful vulnerabilities affecting cloud and SaaS applications. In this episode, he's diving into the latest discovery, a critical vulnerability in Ingress-NGINX:

• How the team uncovered a critical unauthenticated RCE in #NGINX Ingress Controller
• Why Kubernetes admission controllers might be the next big attack surface
• The wild journey of hunting vulnerabilities in the cloud

Listen now:

https://podcasts.apple.com/us/podcast/ingress-nightmare-how-a-single-request-could-take/id1675289400?i=1000700768501
https://open.spotify.com/episode/0G1MmleXvyTjb0wF517kaf?si=yg1nG_NdRbKur-1QjmWbpQ
https://www.youtube.com/watch?v=mjwLEbGA4mk&ab_channel=Wiz

#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:

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

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