Understanding CVE-2025-1974 and Its Impact
Ingress NGINX, a popular Kubernetes ingress controller, translates Ingress objects into NGINX configurations, enabling secure and efficient network routing for containerised applications. The vulnerabilities, collectively referred to as "IngressNightmare," centre around the Ingress NGINX admission controller, which is network-accessible without authentication by default, presenting a major attack vector.
CVE-2025-1974 is particularly critical due to the following reasons:
It can be exploited by any entity on the Pod network.
No administrative credentials are required for exploitation.
Certain network configurations may inadvertently expose the vulnerability.
Successful exploitation could allow attackers to gain unauthorised access to secrets across all namespaces, potentially leading to a complete cluster compromise.
Immediate Recommended Actions
1. Verify Your Installation
Determine if you are using Ingress NGINX by running:
kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx
2. Upgrade Immediately
To mitigate this vulnerability effectively, upgrade to one of the following patched versions:
Ingress NGINX Controller v1.12.1
Ingress NGINX Controller v1.11.5
These versions contain fixes that eliminate the security risk, making an upgrade the most comprehensive solution.
Temporary Mitigation Options
If an immediate upgrade is not possible, implement the following temporary security measures:
Disable Admission Webhooks: If using Helm, reinstall with:
helm upgrade --install ingress-nginx ingress-nginx/ingress-nginx \ --set controller.admissionWebhooks.enabled=false
Delete the ValidatingWebhookConfiguration:
kubectl delete ValidatingWebhookConfiguration ingress-nginx-admission
Modify the Ingress Controller Deployment: Edit the
ingress-nginx-controller
Deployment or DaemonSet and remove the--validating-webhook
argument.
Important: After upgrading to a patched version, re-enable the Validating Admission Controller, as it plays a crucial role in preventing misconfigurations from taking effect.
Strengthening Kubernetes Security Posture
In addition to addressing CVE-2025-1974, organisations should implement broader security best practices to safeguard their Kubernetes environments:
Enforce Network Policies: Restrict access to the admission controller to the Kubernetes API Server.
Segment Networks: Use separate underlay networks for Pods and Services, exposing only essential services.
Regular Security Audits: Continuously review and update security policies to identify and mitigate potential threats.
Apply Strong Access Controls: Implement least privilege principles and role-based access control (RBAC) to minimise attack surfaces.
Monitor and Respond to Threats: Deploy security monitoring tools to detect suspicious activity and respond swiftly.
Conclusion
The CVE-2025-1974 vulnerability highlights the critical importance of proactive security measures in Kubernetes environments. Organisations should act promptly by verifying their installations, upgrading to the latest secure versions, and enforcing best security practices to protect their clusters from potential exploitation.
Stay ahead of security threats — If you need expert assistance in securing your Kubernetes environment, get in touch with our team today.