Ingress-nginx CVE-2025-1974: A Deep Dive into Critical Kubernetes Vulnerabilities

Today, the ingress-nginx maintainers have released patches for a batch of critical vulnerabilities that could enable attackers to compromise your Kubernetes cluster. With over 40% of Kubernetes administrators deploying ingress-nginx, immediate action is paramount to ensure the security of your users and data.

Background

Ingress represents the canonical method in Kubernetes for exposing workload Pods to the outside world. Kubernetes users define desired network access via Ingress objects, leaving it to an ingress controller to interpret these definitions and configure local or cloud resources accordingly, ensuring that the applications are accessible based on specific operational requirements.

Among the various ingress controllers available on the market, ingress-nginx is a software-only solution maintained by the Kubernetes community. Renowned for its flexibility and ease of use, ingress-nginx is now deployed in over 40% of Kubernetes clusters worldwide. This controller works by translating Ingress specifications into configurations for nginx, a highly configurable open source webserver engine. Nginx then routes requests to backend applications, making the proper handling of configuration parameters critical. Misconfigurations can lead to vulnerabilities, enabling attackers to manipulate nginx into behaviors it was never intended to perform.

Vulnerabilities Patched Today

Today’s release addresses five critical vulnerabilities, including four issues that improve how ingress-nginx processes specific nginx configuration snippets. Left unpatched, these issues could allow a maliciously crafted Ingress object to force nginx to accidentally reveal or expose Secrets available to the controller. Since ingress-nginx by default has access to Secrets across the cluster, failure to heed these patches could permit an attacker to rapidly escalate their privileges and potentially take over the cluster.

The most alarming among these is CVE-2025-1974, which carries a 9.8 CVSS rating. This vulnerability exploits configuration injection flaws via the Validating Admission Controller feature, meaning that anyone on the Pod network—even without administrative privileges—can trigger a cluster takeover. In many common cloud and corporate network scenarios, the Pod network is accessible to nearly all workloads, exposing a vast surface area for exploitation.

In response, the ingress-nginx team has released versions v1.12.1 and v1.11.5, which include patches for all five vulnerabilities.

Your Next Steps

First, verify whether your clusters are using ingress-nginx. You can usually confirm its presence by running the command below with cluster administrator permissions:

kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx

If you are using ingress-nginx, please prioritize remediating these vulnerabilities.

The simplest and most effective solution is to upgrade to the latest patch release. This update patches all five vulnerabilities in one step.

For environments where an immediate upgrade is challenging, you can alleviate risk by disabling the Validating Admission Controller feature of ingress-nginx:

• If installed via Helm:
  • Reinstall with the Helm value set as controller.admissionWebhooks.enabled=false
• If installed manually:
  • Delete the ValidatingWebhookConfiguration named ingress-nginx-admission
  • Edit the ingress-nginx-controller Deployment or DaemonSet, removing the --validating-webhook argument from the container’s configuration

Remember to re-enable the Validating Admission Controller post-upgrade to regain its benefits in warning users of misconfigurations.

Deep Dive: How Ingress-nginx Integrates with Nginx

Under the hood, ingress-nginx acts as a mediator between the Kubernetes Ingress definitions and nginx configurations. It parses user-defined Ingress specifications into a detailed nginx configuration file. This file governs how incoming network packets are handled and routed to designated backend services. With advanced features like TLS termination, URL rewriting, and load balancing, nginx becomes a powerful tool but one that requires robust validation to prevent misconfigurations that lead to security risks.

The vulnerability CVE-2025-1974 leverages flaws in this translation process, enabling attackers on the Pod network to inject malicious configuration parameters remotely. Experts note that correctly managing configuration scope and access rights within the nginx context is paramount, as even minor oversights can lead to severe security breaches.

Expert Insights: Securing Kubernetes Ingress Controllers

Security professionals emphasize that managing ingress controllers is not just about keeping software up-to-date but also ensuring hardened deployment practices. According to industry experts, the following best practices are recommended:

• Regularly audit Ingress configurations to verify that only authorized entities have creation rights.
• Implement additional network segmentation for the Pod network to reduce lateral movement risks.
• Deploy role-based access control (RBAC) policies meticulously to limit who can define or modify Ingress resources.
• Monitor ingress traffic and logs in real-time using centralized logging solutions and SIEM systems to detect unusual access patterns.

These measures, combined with timely software updates, provide a layered defense that minimizes the potential impact of future vulnerabilities.

Future Trends: Enhancing Kubernetes Ingress Security

Looking forward, the Kubernetes ecosystem is expected to place even greater emphasis on security hardening of ingress components. With the increasing adoption of microservices architectures and multi-cloud deployments, the complexity and risk profile of ingress setups will continue to evolve.

Recent discussions within the Kubernetes Security Response Community (KSRC) suggest that upcoming versions may include intrinsic security validations and better integration with centralized authentication systems. Moreover, some proposals advocate for more granular access controls at the ingress level, which would enable administrators to define security policies in tandem with routing rules.

These forward-looking measures aim to reduce dependency on workarounds like disabling critical features, thereby fostering a more secure, resilient infrastructure that can better withstand sophisticated attacks.

Conclusion, Thanks, and Further Reading

The vulnerabilities, particularly CVE-2025-1974, present a severe risk to Kubernetes users. If you depend on ingress-nginx, it is crucial to act swiftly—either by upgrading to the patched versions or by temporarily mitigating the risk by disabling the vulnerable feature.

Special thanks to Nir Ohfeld, Sagi Tzadik, Ronen Shustin, and Hillai Ben-Sasson from Wiz for their responsible vulnerability disclosure, as well as to Kubernetes SRC members and ingress-nginx maintainers, Marco Ebert and James Strong, for their prompt remediation efforts.

For additional context on ingress-nginx maintenance and future directions, refer to the ongoing discussion in this GitHub issue or attend James and Marco’s upcoming presentation at KubeCon/CloudNativeCon EU 2025.

Further details on the individual vulnerabilities can be found in the respective GitHub issues: CVE-2025-24513, CVE-2025-24514, CVE-2025-1097, CVE-2025-1098, and CVE-2025-1974.

Источник: Kubernetes Blog