Unauthenticated Remote Code Execution in Ingress NGINX (CVE-2025-1974)

A critical vulnerability, CVE-2025-1974, in the Kubernetes Ingress-NGINX Controller makes unauthenticated remote code execution possible, allowing attackers to execute arbitrary code without authentication. Along with related flaws, it has been dubbed "Ingress Nightmare" by cloud security company Wiz.

Overview

CVE-2025-1974 carries a CVSS score of 9.8 (Critical). It allows attackers to execute arbitrary code without authentication by targeting the admission controller.

Ingress Nightmare: The Vulnerability Cluster

The following CVEs are part of the Ingress Nightmare suite:

• CVE-2025-24513 - Improper input validation may cause directory traversal or denial of service (CVSS 4.8).
• CVE-2025-24514 - Exploiting the auth-url annotation allows arbitrary code execution (CVSS 8.8).
• CVE-2025-1097 - Exploits via match-cn for auth-tls enable unauthorized code execution (CVSS 8.8).
• CVE-2025-1098 - Injecting configuration through mirror-host and mirror-target annotations can lead to RCE (CVSS 8.8).
• CVE-2025-1974 - Allows unauthenticated RCE through the admission controller (CVSS 9.8).

The NGINX Ingress Controller, which is distinct from the Kubernetes Ingress-NGINX Controller, is unaffected.

What Is Kubernetes Ingress?

Ingress is a Kubernetes API object that manages external access to services, typically HTTP and HTTPS, using hostnames, paths, SSL/TLS termination, and load balancing. An Ingress Controller like Ingress-NGINX completes this function by converting Ingress objects into real routing configurations.

How CVE-2025-1974 Enables Remote Code Execution

The vulnerability lies in the Ingress-NGINX admission controller, which validates incoming ingress objects. Attackers can:

1. Craft malicious ingress objects with a specially formed auth-url annotation.
2. Send these directly to the admission controller over the network, without authentication.
3. Inject arbitrary NGINX directives using annotations.
4. Upload a malicious shared object (.so) via an HTTP POST to the pod.
5. Trigger nginx -t to validate the injected config, loading the attacker's shared library.

The ssl_engine directive in OpenSSL was key to enabling arbitrary library loading during config validation.

Affected Versions

• Affected: Ingress-NGINX Controller earlier than v1.11.5, and all v1.11.x versions before v1.11.5.
• Fixed in: v1.11.5 and v1.12.1 and later.

Remediation and Best Practices

Secure your Kubernetes clusters immediately:

1. Upgrade to a fixed version (v1.12.1 or later).
2. Disable validating admission webhooks temporarily (via Helm controller.admissionWebhooks.enabled=false, or manually by deleting ingress-nginx-admission and updating deployment args).
3. Audit ingress rules with kubectl get ingress --all-namespaces.
4. Isolate namespaces to avoid lateral movement.
5. Restrict ingress changes to authorized users only.
6. Apply network policies to restrict pod access.
7. Enforce HTTPS and use strong TLS ciphers.
8. Monitor Kubernetes audit logs with ELK, Prometheus, Grafana, or Falco.
9. Use a WAF such as ModSecurity or AWS WAF.
10. Scan YAML and Helm charts for misconfigurations using OPA or Kyverno.
11. Run Kubernetes security scanners such as kube-bench and kube-hunter.

Disable the admission controller only temporarily. Reactivate it after upgrading to restore security validations.

Conclusion

Ingress Nightmare is a reminder that infrastructure components need the same security scrutiny as applications. Comprehensive Kubernetes security assessments should include infrastructure and configuration reviews, ingress and admission controller hardening, vulnerability and misconfiguration scanning, CI/CD integration for DevSecOps, and container security testing. Stay ahead of zero-days.