Recently, the cloud security company Wiz disclosed a significant set of vulnerabilities affecting the popular Kubernetes ingress-nginx controller. Given its widespread use, understanding the risk and necessary actions is crucial for Kubernetes administrators and security teams. This article breaks down the vulnerability, its potential impact, how to exploit it, and, most importantly, how to fix it and learn from it.

What is the Vulnerability?

Discovered by the Wiz Research Team, the core issue (tracked primarily as CVE-2025-1974 lies within the admission controller part of ingress-nginx. Shockingly, it seems this vulnerability has existed almost since the beginning of the project!

For a deep dive into the technical specifics, refer to the detailed write-up by Wiz.

How Can It Be Exploited?

Exploiting this vulnerability isn’t trivial and requires specific prerequisites:

  1. Cluster API Access: The attacker must already have some level of access within the Kubernetes cluster that allows them to communicate with a ingress-nginx pod via its Service. This could be achieved through:
    • Gaining shell access to an existing pod running in the cluster.
    • Deploying a new pod from a special container image with malicious commands defined (either in the pod spec or within the container image’s entrypoint).
  2. Additional expertise and resources: The attacker might need the ability to write a specific shared library that is required to gain shell access from within a ingress-nginx, which requires further permissions or vulnerabilities. The Wiz team demonstrated a potential exploit path in a short video, but they have not published the full exploit script. This means attackers need to develop their own specific exploit based on the vulnerability details.

How Critical Is It?

⚠️ Extremely critical. Here are the reasons:

  • CVSS Score: The vulnerability carries a CVSS v3.1 base score of 9.8 (Critical). Scores this high indicate a severe vulnerability that is relatively easy to exploit (assuming the prerequisites are met) and has a significant impact.
  • Prevalence: According to Wiz, over 40% of cloud environments might be running a vulnerable version of ingress-nginx. This widespread exposure makes the potential impact massive.
  • Potential Impact: A successful attacker gains the permissions associated with the ingress-nginx controller itself. This typically includes the ability to:
    • Read all Services: Discover internal network topology and potentially find other vulnerable services.
    • Read all ConfigMaps: Access potentially sensitive configuration data.
    • 🔴 (The Worst Part) Read all Secrets: This is the most damaging outcome. An attacker gaining access to all Kubernetes secrets within the cluster (API keys, database credentials, tokens, etc.) can lead to a complete cluster compromise and potentially spread to other systems.

How to Fix It

Mitigation is relatively straightforward:

  1. Update ingress-nginx: The primary fix is to update your ingress-nginx controller to the latest patched version. Follow the official upgrade guide for your deployment method (Helm, manifests, etc.).
  2. Temporary Workaround (If Update Is Impossible): If you absolutely cannot update immediately, you can mitigate the risk by disabling the admission controller webhook. This is done by setting the Helm chart value controller.admissionWebhooks.enabled=false or removing the --enable-admission-webhooks=true flag from the controller’s deployment arguments.
    Warning: Disabling the webhook removes validation safeguards and is not recommended as a long-term solution. Upgrade as soon as possible.

Five Lessons for the Future

This vulnerability serves as a stark reminder that even widely used components can harbor critical flaws. Prepare for future vulnerabilities, including zero-days, by adopting robust security practices:

  1. Restrict Egress Traffic: Limit outbound network connections from your cluster pods using Network Policies and external firewalls. This makes it harder (though not impossible) for attackers to download malicious tools (like kubectl) or exfiltrate data after gaining initial access.
  2. Minimize User Access (Embrace GitOps): Avoid giving users direct kubectl apply access to the cluster. Use GitOps workflows where changes are proposed via Git pull requests, reviewed (manually and potentially automatically with AI tools), and then automatically applied by a trusted agent (like Argo CD or Flux).
  3. Eliminate Shells in Containers: Do you really need a shell (/bin/sh, /bin/bash) inside your production containers? Often, you don’t. Remove shell binaries from your container images to significantly reduce the attack surface if an attacker gains execution within a container. For debugging, leverage Kubernetes’ ephemeral containers feature.
  4. Use Trusted Images and Admission Control: Restrict the container registries allowed within your cluster. Use tools like Kyverno, Gatekeeper or builtin ValidatingAdmissionPolicy to enforce policies that only permit images from approved sources and potentially scan images for known vulnerabilities before deployment.
  5. Manage Your Platform with Code (IaC/GitOps): When infrastructure and platform components (like ingress-nginx) are managed declaratively via code (Terraform, Helm charts in Git, etc.), applying updates and patches across environments becomes significantly faster and more reliable. Fixing this vulnerability could be reduced to updating a version number in a Git repository and letting the GitOps process handle the rollout.

Conclusion

The ingress-nginx vulnerability is a serious threat due to its high CVSS score, widespread deployment, and the potential for complete cluster compromise via secret theft.
While exploitation requires pre-existing cluster access, the potential impact necessitates immediate action. Updating the controller is the definitive fix. Furthermore, this incident underscores the critical need for layered security, least privilege principles (via GitOps), and managing infrastructure as code to respond effectively to future security challenges.

If you need help in fixing and secduring your cluster, I offer free consulting to companies that want to check, fix and secure their Kubernetes clusters.
👉 See here for more info.