security

Patch Now: Ingress-NGINX Vulnerabilities Let Hackers Steal All Kubernetes Secrets

Spread the love

A research was conducted and critical series of vulnerabilities have been found (CVE-2025-1097, CVE-2025-1098, CVE-2025-24514, CVE-2025-1974) in the Ingress NGINX Controller for Kubernetes, collectively dubbed “IngressNightmare.” These unauthenticated Remote Code Execution (RCE) vulnerabilities allow attackers to gain unauthorized access to all secrets across all namespaces in a Kubernetes cluster, potentially leading to complete cluster takeover.

Key Details

Affected Component

– The admission controller component of Ingress NGINX Controller (used by ~41% of internet-facing clusters)

– CVSS v3.1 base score: 9.8 (Critical)

– Estimated 43% of cloud environments vulnerable

Technical Analysis

The vulnerabilities stem from how the admission controller processes Ingress objects:

1. The controller creates temporary NGINX configurations from Ingress objects

2. Validates them using `nginx -t`

3. Multiple injection points allow attackers to inject malicious NGINX directives

4. The `ssl_engine` directive can be abused to load arbitrary shared libraries

5. Combined with a file upload technique via NGINX’s client body buffering, this leads to RCE

Specific Vulnerabilities

1. CVE-2025-24514: Auth-url annotation injection

2. CVE-2025-1097: Auth-tls-match-cn annotation injection

3. CVE-2025-1098: Mirror UID injection

4. CVE-2025-1974: NGINX configuration code execution via `ssl_engine`

Impact

Successful exploitation allows:

– Remote code execution on the Ingress NGINX Controller pod

– Access to all cluster secrets across all namespaces

– Potential complete cluster takeover

Mitigation Recommendations

Immediate Actions

1. Update to patched versions:

– Ingress NGINX Controller v1.12.1

– Ingress NGINX Controller v1.11.5

2. Restrict access to admission webhook endpoints:

– Ensure they’re not exposed externally

– Implement network policies to allow only Kubernetes API server access

3. Temporary workarounds if immediate upgrade isn’t possible:

For immediate mitigation, organizations should disable the admission controller component entirely if they cannot immediately patch. For Helm-based installations, this can be done by setting controller.admissionWebhooks.enabled=false during deployment. For manual installations, administrators must delete the ValidatingWebhookConfiguration resource named ingress-nginx-admission and remove the –validating-webhook argument from the ingress-nginx-controller’s Deployment or DaemonSet. While this temporarily removes an important safeguard, it effectively eliminates the attack vector until a proper upgrade can be performed. Remember to re-enable validation after applying the security patches to restore critical configuration checks.

Detection

To detect vulnerable systems, security teams should immediately scan their Kubernetes clusters using the provided Nuclei template to identify any exposed admission controllers that could be targeted by attackers. Additionally, organizations must implement continuous monitoring to detect anomalous AdmissionReview requests, particularly those containing unusual NGINX directives or unexpected annotations, as these may indicate active exploitation attempts. These proactive detection measures are critical for identifying and securing vulnerable systems before attackers can leverage them for cluster compromise.

Attack Flow

An attacker begins by gaining initial access to the cluster network—often through a compromised pod, SSRF vulnerability, or other entry point—then crafts a malicious AdmissionReview request containing injected NGINX directives. By exploiting client body buffering, they force NGINX to temporarily store a malicious shared library on disk, even though the file is quickly deleted. However, the attacker leverages procfs to access the lingering file descriptor, then uses the ssl_engine directive to load the rogue library during NGINX’s configuration validation phase. This ultimately grants them remote code execution (RCE) on the Ingress-NGINX Controller pod with elevated privileges, enabling access to all cluster secrets and potential full cluster takeover.

Key Insights

– Admission controllers present a significant, often overlooked attack surface

– Default configuration lacks authentication and proper network restrictions

– NGINX configuration validation (`nginx -t`) can be dangerous with unsanitized input

– Controller runs with excessive privileges (access to all cluster secrets)

Conclusion

The IngressNightmare vulnerabilities highlight critical security risks in Kubernetes ingress controllers, particularly around admission webhooks. Organizations should prioritize patching and review their ingress controller configurations to prevent potential cluster compromise.

This research also underscores the importance of proper privilege management and network segmentation in Kubernetes environments.

An abridged version of the original post here


Spread the love

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top
×