How to fix CVE-2025-1974 Vulnerability in Ingress-NGINX: A Step-by-Step Guide for Kubernetes Clusters

Rahul JainRahul Jain
4 min read

On March 24, 2025, the Kubernetes project disclosed a critical security vulnerability - CVE-2025-1974 - affecting the widely-used ingress-nginx controller.

Other related vulnerabilities include:
CVE-2025-24513, CVE-2025-24514, CVE-2025-1097, CVE-2025-1098

If you’re among the 40%+ of Kubernetes administrators using ingress-nginx, immediate action is recommended to protect your users and infrastructure.

In this post, I’ll walk you through:

  • What this vulnerability is

  • How to check if you're affected

  • How to patch it (both Helm and non-Helm setups)

  • How to keep your configuration intact

  • Temporary mitigation options if you can’t upgrade right away

  • Roll back steps

  • How I resolved a real-world webhook error

📌 What Is CVE-2025-1974?

This vulnerability allows unauthenticated attackers within the Kubernetes pod network to achieve remote code execution in the ingress-nginx controller pod. It exploits how user-provided annotations (like server-snippet) are handled by the ingress-nginx validating webhook. If exploited, it could potentially allow access to all secrets the controller can see - leading to full cluster compromise.

More details: Kubernetes Official Blog


🔍 Step 1: Check If You’re Affected

To verify whether ingress-nginx is running in your cluster:

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

If this returns results, you’re likely running ingress-nginx and should proceed with checking the version.

🔢 Step 2: Check Your Current Ingress-NGINX Version

If installed via Helm, run:

helm list -n <your-namespace>

And check the CHART name and APP VERSION.

Or check the image tag:

kubectl get deployment <deployment-name> -n <your-namespace> -o=jsonpath='{$.spec.template.spec.containers[:1].image}'

This results in output as:

registry.k8s.io/ingress-nginx/controller:<version>@<sha-id>

If your version is:

  • < v1.11.0

  • v1.11.0 - v1.11.4

  • v1.12.0

➡️ You are vulnerable.

🔧 Step 3.1: Patch Using Helm (If You Installed Using Helm)

First, add the Helm repo if it was removed:

helm repo list
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update

✅ Keep Existing Configurations

You can upgrade without overwriting the current configuration by exporting and reusing existing values:

helm get values <your-Helm-release> -n <your-namespace> -o yaml > values.yaml

Then:

helm upgrade <your-Helm-release> ingress-nginx/ingress-nginx --namespace <your-namespace> --version 4.12.1 -f values.yaml

🛠️ Step 3.2: If Not Using Helm

If you deployed ingress-nginx manually (e.g., using static manifests), edit the Deployment directly:

kubectl edit deployment <your-deployment-name> -n <your-namespace>

Update the container image tag to the latest patched version. Then save and exit. This will trigger a rollout.


🛡️ Temporary Mitigation (If You Can’t Upgrade Right Away)

If you can’t upgrade right away, you can significantly reduce your risk by turning off the Validating Admission Controller feature of ingress-nginx.

  • If you have installed ingress-nginx using Helm

    • Reinstall, setting the Helm value controller.admissionWebhooks.enabled=false
  • If you have installed ingress-nginx manually

    • delete the ValidatingWebhookconfiguration called ingress-nginx-admission

    • edit the ingress-nginx-controller Deployment or Daemonset, removing --validating-webhook from the controller container’s argument list

If you turn off the Validating Admission Controller feature as a mitigation for CVE-2025-1974, remember to turn it back on after you upgrade. This feature provides important quality of life improvements for your users, warning them about incorrect Ingress configurations before they can take effect.


🔄 Rollback Steps (If Needed)

To find previous versions:

helm history <your-Helm-release> -n <your-namespace>

If something breaks and you need to rollback:

helm rollback <your-Helm-release> <REVISION_NUMBER> --namespace <your-namespace>

🧱 Resolving Webhook Error for Snippet Annotation (if occurs)

After upgrading, I faced this error when applying an Ingress resource:

admission webhook "validate.nginx.ingress.kubernetes.io" denied the request: nginx.ingress.kubernetes.io/server-snippet annotation cannot be used.

This happened because, starting with v1.8.0, ingress-nginx disabled snippet annotations by default for security reasons.

✅ To Fix This:

Remove the server-snippet annotation from your Ingress resource.

If you intentionally use custom nginx directives, you can re-enable snippet annotations (use with caution):

helm upgrade <your-Helm-release> ingress-nginx/ingress-nginx \
  --namespace <your-namespace> \
  --reuse-values \
  --set-string controller.allowSnippetAnnotations="true"

Or, edit the ConfigMap used by ingress-nginx:

allow-snippet-annotations: "true"

Or remove the server-snippet annotation from your Ingress resource entirely, if it's not critical.


🧠 Final Thoughts

This vulnerability is a strong reminder of the importance of regular security reviews and proper controls in admission webhooks. Even a flexible tool like ingress-nginx can become an attack vector if configurations are not securely validated.

If you haven’t patched yet, disable the validating webhook immediately and plan your upgrade strategy today. Whether you're using ingress-nginx for dev or production, make sure to:

  • Regularly check CVEs and patch early

  • Restrict access to admission webhooks

  • Audit annotations and config snippets used in your manifests


📘 Resources

0
Subscribe to my newsletter

Read articles from Rahul Jain directly inside your inbox. Subscribe to the newsletter, and don't miss out.

Written by

Rahul Jain
Rahul Jain

Hi, I’m Rahul Jain, Senior DevOps & Cloud Engineer and Microsoft Certified: DevOps Engineer Expert with a passion for automation, cloud optimization, and efficient software delivery. I specialize in building CI/CD pipelines, automating complex deployments, and leveraging cloud services to create scalable, and reliable solutions. With hands-on experience in DevOps, Azure, AWS, Docker, Kubernetes, and Terraform, I thrive on transforming manual processes into seamless, automated workflows that drive efficiency and innovation. I bring strong technical, interpersonal, and communication skills, enabling effective collaboration and problem-solving in dynamic environments. Passionate about driving efficiency and scalability in IT operations, I’m always open to new challenges that push the boundaries of DevOps excellence.