Full Report
We share actionable mitigation and detection strategies against IngressNightmare so you can protect against possible exploitation in runtime.
Analysis Summary
# Vulnerability: IngressNightmare - RCE in Kubernetes Ingress NGINX Controller
## CVE Details
- CVE ID: CVE-2025-1097, CVE-2025-1098, CVE-2025-24514, CVE-2025-1974
- CVSS Score: 9.8 (Critical) (For CVE-2025-1974)
- CWE: Not explicitly listed, related to Injection/Configuration flaws.
## Affected Systems
- Products: Ingress NGINX Controller for Kubernetes.
- Versions: All versions prior to v1.11.0, versions v1.11.0 through v1.11.4, Version v1.12.0.
- Configurations: Vulnerabilities are leveraged via the controller’s admission webhook, generally when misconfigurations or exposed entry points exist.
## Vulnerability Description
The collective vulnerabilities termed "IngressNightmare" in the Ingress NGINX Controller allow for unauthenticated Remote Code Execution (RCE) via exploiting weaknesses related to annotation processing within the admission webhook. An attacker crafts a malicious Ingress resource containing injected NGINX configurations (related to `auth-tls-match-cn`, `mirror-uid`, and `auth-url` annotations). When the controller validates this configuration using `nginx -t`, the injected code is executed with the controller's elevated privileges, leading to potential cluster compromise.
## Exploitation
- Status: Potential for exploitation (implied high risk based on RCE and accessibility checks). PoC methodology is detailed in the discovery process.
- Complexity: Assumed Medium to High, as it requires crafting a specific malicious Ingress object and relies on the admission webhook process.
- Attack Vector: Network (Remote, unauthenticated access to the admission controller).
## Impact
- Confidentiality: High (Unauthorized access to all cluster Secrets across namespaces).
- Integrity: High (Ability to modify/control the cluster).
- Availability: High (Potential for cluster takeover/disruption).
## Remediation
### Patches
Immediate upgrade is required:
- Update to v1.11.5 or later.
- Update to v1.12.1 or later.
### Workarounds
While patching is the primary defense, the article suggests checking for current exposure using:
`kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx`
For operational troubleshooting (not directly a security workaround, but aids performance):
1. **Monitor Resource Usage:** `kubectl top pod -n ingress-nginx`
2. **Optimize Configuration:** Set buffering via annotations (e.g., `proxy-buffering: "on"`, `proxy-buffer-size: "8k"`, `proxy-body-size: "10m"`).
3. **Scale Horizontally:** Increase replicas if needed: `kubectl scale deployment ingress-nginx-controller -n ingress-nginx --replicas=3`
## Detection
- **Indicators of Compromise (IOCs):** Potential unauthorized access to Secrets post-exploitation, lateral movement attempts within the cluster, and high CPU usage on Ingress controllers during attack attempts.
- **Detection Methods and Tools:** Runtime security solutions (like SentinelOne Singularity Platform) can highlight both vulnerability exposure and monitor for post-exploitation activity. Monitoring for unusual NGINX configuration loading or execution attempts during validation checks is crucial.
## References
- Vendor advisories (Implied by CVE tracking).
- Relevant links - defanged:
- kubernetes dot io/docs/concepts/services-networking/ingress-controllers/
- nvd dot nist dot gov/vuln/detail/CVE-2025-1097
- nvd dot nist dot gov/vuln/detail/CVE-2025-1098
- nvd dot nist dot gov/vuln/detail/CVE-2025-24514
- nvd dot nist dot gov/vuln/detail/CVE-2025-1974
- sentinelone dot com/platform/cloud-security/
- sentinelone dot com/blog/climbing-the-ladder-kubernetes-privilege-escalation-part-1/
- sentinelone dot com/blog/climbing-the-ladder-kubernetes-privilege-escalation-part-2/