Today, when I woke up and checked my RSS feed, one headline stood out immediately, CVE-2025-1974. It’s a new high-severity vulnerability in , and it’s bad. Like bad.
ingress-nginx
"any pod in your cluster can potentially take over your entire Kubernetes environment without credentials"
Naturally, I dropped everything and dug into the advisory.
The ingress-nginx maintainers just dropped patches for five security vulnerabilities. The most critical among them—CVE-2025-1974—has a CVSS score of 9.8. It allows configuration injection via the Validating Admission Controller, meaning any workload on the Pod network could potentially compromise your cluster.
Let that sink in: even if a user or service doesn’t have permission to create Ingress objects, it could still exploit this path—just by being on the same network.
For context, ingress-nginx is a widely used ingress controller in Kubernetes (deployed in 40%+ clusters). It translates Ingress resources into NGINX configurations to route external traffic to internal services. It's flexible, easy to deploy—and now, evidently, a big attack surface.
Ingress controllers usually require elevated privileges. But this particular flaw means that even low-privileged pods can interact with the Validating Admission Controller in unintended ways. Combine that with other config handling issues patched today, and you’re looking at a cluster-wide exposure scenario.
Here's What You Must Do: Upgrade Immediately (Recommended)¶
✅ Best-case fix: Upgrade to a patched version.
Patched versions available:
v1.12.1
v1.11.5
Upgrading ensures you're protected not just from CVE-2025-1974 but also from four other related vulnerabilities fixed in this release.
Re-enable the Validating Admission Controller after you’ve upgraded to a patched version—it’s there for a reason: to prevent misconfigured Ingress resources from being applied.
CVE-2025-1974 is a high-severity vulnerability (CVSS 9.8) in ingress-nginx that allows configuration injection via the Validating Admission Controller. It enables any pod on the cluster network to potentially compromise the entire Kubernetes environment, even without Ingress creation permissions.
How does this vulnerability affect Kubernetes clusters using ingress-nginx?
Even low-privileged pods can exploit the Validating Admission Controller to inject malicious configuration. Since ingress-nginx runs with elevated privileges in many clusters, this creates a pathway for full-cluster compromise.
What’s the recommended fix for CVE-2025-1974?
Upgrade immediately to a patched version of ingress-nginx:
v1.12.1
v1.11.5 This addresses CVE-2025-1974 and four other related vulnerabilities without removing key features.
What are the alternatives if an upgrade isn’t possible right away?
You can disable the Validating Admission Controller temporarily by removing its container args and webhook configs. However, this also disables safeguards against invalid Ingress resources, so it should be re-enabled post-upgrade.
Is there a last-resort mitigation if neither upgrade nor disabling is viable?
Yes. As a last resort, you can deploy a DaemonSet that configures iptables rules to block all external traffic to port 8443, used by the webhook, while allowing access only from the Kubernetes API server. This mitigates the vulnerability at the network layer, but use it with caution, as it has not been widely tested in production environments.
Like what you read? Support my work so I can keep writing more for you.
GitHub cut hosted runner prices but planned fees for self-hosted Actions, triggering backlash. The change was paused. Here’s what happened and what to expect.