CVE-2025-1974 How to Check and Update Kubernetes ingress-nginx Version

Key Summary and Immediate Solutions

1. Vulnerable Versions and Identification Methods

• Vulnerable Versions: All versions of ingress-nginx Controller below v1.12.1 and below v1.11.5 are potentially vulnerable. (Specifically applies to CVE-2025-1974, CVE-2025-24513, CVE-2025-24514, CVE-2025-1097, CVE-2025-1098)
• Version Identification Method: Execute the command below with cluster administrator privileges to find the ingress-nginx pods and identify the version by checking the image tag of the respective pod.

  kubectl get pods --all-namespaces -l app.kubernetes.io/name=ingress-nginx -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{range .spec.containers[*]}{.image}{"\n"}{end}{end}'

  # 1. Find Pod (Check Namespace)
  kubectl get pods --all-namespaces -l app.kubernetes.io/name=ingress-nginx
  
  # 2. Check Image Information of the Found Pod (e.g., if pod name is 'ingress-nginx-controller-xxxxx' and namespace is 'ingress-nginx')
  kubectl describe pod ingress-nginx-controller-xxxxx -n ingress-nginx | grep Image:

  If you cannot confirm directly with the above command, try kubectl get pods -A | grep ingress-nginx

  Note: In some environments like RKE2, the label selector might differ (e.g., app.kubernetes.io/name=rke2-ingress-nginx). Adjust the selector according to your environment.

  If you have difficulty confirming the version using the methods above, you can also check the version by directly accessing the pod. Use the command below (change the pod name and namespace according to your actual environment):

  # Check nginx version by directly accessing the pod
  kubectl exec -it ingress-nginx-controller-xxxxx -n ingress-nginx -- nginx -v

  This command directly executes the nginx -v command inside the pod to display the version. Depending on the image, other commands or file path checks might be necessary.

2. Solution: Upgrade to a Stable Version (Recommended)

It is recommended to upgrade immediately to a version where the vulnerability has been patched.

• Stable Versions: Version v1.12.1 or v1.11.5 or higher. However, you must select a version compatible with your current Kubernetes version.
• Check Kubernetes Version Compatibility: Before upgrading, be sure to check the Ingress-NGINX version compatible with your current Kubernetes version. The table below shows the Kubernetes support range for recent stable versions. (Refer to the official documentation for complete compatibility information.)
  
  

  Supported Ingress-NGINX version	k8s supported version	Alpine Version	Nginx Version	Helm Chart Version
  🔄 v1.12.1	1.32, 1.31, 1.30, 1.29, 1.28	3.21.3	1.25.5	4.12.1
  🔄 v1.12.0	1.32, 1.31, 1.30, 1.29, 1.28	3.21.0	1.25.5	4.12.0
  🔄 v1.12.0-beta.0	1.32, 1.31, 1.30, 1.29, 1.28	3.20.3	1.25.5	4.12.0-beta.0
  🔄 v1.11.5	1.30, 1.29, 1.28, 1.27, 1.26	3.21.3	1.25.5	4.11.5

  
  For example, if you are using Kubernetes v1.29, you can choose Ingress-NGINX v1.12.1, v1.12.0, v1.11.5, etc. You can check the current cluster's Kubernetes version with the kubectl version command.
• Detailed Ingress-NGINX Upgrade Guide

  This is the procedure for upgrading the ingress-nginx controller to a version with security patches applied (v1.11.5 or v1.12.1 or higher). Unexpected situations may occur, so please ensure you have backups ready before proceeding.

  I. Preparation

  1. Check Current Status:
     • Accurately check the currently used ingress-nginx version and installation method (Helm or Manifest)
     • Using Helm: helm list -n
     • Using Manifest: Check the image tag of the controller Pod
       

       kubectl get pod -n  -l app.kubernetes.io/name=ingress-nginx -o jsonpath='{.items[0].spec.containers[?(@.name=="controller")].image}'

       (Label selector may vary depending on the environment.)
  2. Determine Target Version (Apply Security Patch):
     • Select a version v1.11.5 or v1.12.1 or higher that suits your current environment and requirements.
  3. Final Compatibility Check (Very Important!):
     • Finally, confirm that the selected target ingress-nginx version is compatible with the currently operating Kubernetes cluster version.
     • Check current cluster version: kubectl version
  4. Backup Current Configuration:
     • Using Helm: Save the currently applied configuration values to a file.

       helm get values  -n  > ingress-nginx-backup-values-$(date +%Y%m%d%H%M%S).yaml

       (Replace and with actual values.)
     • Using Manifest: Back up all relevant YAML files in use (Deployment/DaemonSet, Service, ConfigMap, RBAC, etc.) to a safe place, or save the configuration using the kubectl get ... -o yaml command.

       # Example: Backup Deployment configuration
       kubectl get deployment -n  -l app.kubernetes.io/name=ingress-nginx -o yaml > ingress-nginx-deployment-backup-$(date +%Y%m%d%H%M%S).yaml

  5. Prepare Helm Repository (Using Helm):
     • Add the official ingress-nginx Helm repository and fetch the latest information.

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

  II. Execute Upgrade (Goal: Resolve CVE)

  Method 1: Using Helm (Recommended)

  1. Execute Upgrade Command:
     • Specify the Helm chart version corresponding to the target security patch version (e.g., v1.11.5 or v1.12.1) in the --version flag.
     • Use the backed-up configuration file (-f) to maintain existing settings as much as possible.
     • (Recommended) Use the --dry-run option to preview changes before actual application.
     • (Optional) Use the --atomic option to enable automatic rollback on failure.

     # Example: Upgrade to v1.11.5 (assuming chart 4.11.5)
     # 1. Check changes with Dry-run
     helm upgrade  ingress-nginx/ingress-nginx \
       --version 4.11.5 \
       -n  \
       -f ingress-nginx-backup-values-....yaml \
       --dry-run
     
     # 2. After checking Dry-run results, perform actual upgrade (add --atomic if needed)
     helm upgrade  ingress-nginx/ingress-nginx \
       --version 4.11.5 \
       -n  \
       -f ingress-nginx-backup-values-....yaml

     • Caution: If there are items in the backed-up configuration values that have been changed/removed in the new version, you may need to check with --dry-run and modify the values.yaml file.

  Method 2: Using Manifest File (kubectl apply)

  1. Download Security Patch Version Manifest:
     • Download the official deploy.yaml file for the target security patch version (e.g., v1.11.5 or v1.12.1) from the GitHub release page, etc. (Select the file appropriate for your environment - cloud, baremetal, etc.)

     # Example: Download deploy.yaml for cloud environment, version v1.11.5 (URL needs to be verified for the actual version)
     wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.11.5/deploy/static/provider/cloud/deploy.yaml

  2. (Recommended) Compare Changes: Check the differences between the existing configuration (backup file) and the newly downloaded Manifest file (using diff command, etc.), and carefully reflect any necessary custom settings in the new file.
  3. Apply Manifest:

     kubectl apply -f deploy.yaml -n 

  III. Post-Upgrade Verification

  1. Check Pod Status and Version: Verify that the controller Pod has restarted successfully with the target security patch version image.

     kubectl get pods -n  -l app.kubernetes.io/name=ingress-nginx
     kubectl describe pod -n   | grep Image:

  2. Check Logs: Verify that there are no errors in the controller Pod logs.

     kubectl logs -n  -l app.kubernetes.io/name=ingress-nginx --tail=100

  3. Functional Testing: Verify that services exposed via Ingress are functioning correctly using various methods (browser access, API calls, etc.).
  4. Check Admission Controller (if enabled): Ensure related Pods (ingress-nginx-admission-create, ingress-nginx-admission-patch, etc.) are normal, and perform related functional tests like Ingress creation/modification if necessary.

  IV. Temporary Mitigation Measures (If immediate upgrade is not possible)

  Caution: The measures below only temporarily reduce the risk of CVE-2025-1974 and may still leave you exposed to other vulnerabilities. This is not a fundamental solution, so you must upgrade to a security-patched version as soon as possible.

  1. Temporarily Disable Validating Admission Controller Feature:
     • Using Helm:

       helm upgrade  ingress-nginx/ingress-nginx \
         -n  \
         --set controller.admissionWebhooks.enabled=false \
         -f ingress-nginx-backup-values-....yaml # Specify the existing values file as well

     • Using Manifest:
       1. Delete ValidatingWebhookConfiguration (Resource name needs verification):

          kubectl delete validatingwebhookconfiguration ingress-nginx-admission -n 

       2. Edit Controller Deployment/DaemonSet: Open the editor with the command kubectl edit deployment -n , find and remove the --validating-webhook=... related argument from the spec.template.spec.containers.args list, then save.
  2. Re-enable After Upgrade: After completing the upgrade to the security-patched version, you must re-enable the previously disabled Admission Controller (Helm: set controller.admissionWebhooks.enabled=true, Manifest: reapply related resources).

  V. Rollback in Case of Problems

  1. Using Helm:

     # 1. Check previous revision
     helm history  -n 
     
     # 2. Rollback to previous revision (e.g., if previous revision number is 5)
     helm rollback  5 -n 

  2. Using Manifest: Reapply using the backed-up Manifest file(s) of the previous version with the command kubectl apply -f .

  VI. Final Recommendations

  • Test Environment Verification: Before applying to the production environment, always perform thorough verification in a similar test environment such as staging.
  • Monitoring: Closely monitor the system status (CPU, memory usage, error rate, response time, etc.) before and after the upgrade.

  We hope this verified guideline helps you resolve the ingress-nginx security vulnerability safely and effectively.

---

Cause of CVE-2025-1974 Vulnerability

The CVE-2025-1974 (CVSS 9.8) vulnerability occurs in the Validating Admission Controller feature of ingress-nginx. This feature validates whether the configuration is correct when a user creates or modifies an Ingress object.

Through this vulnerability, an attacker with access to the Pod network can send specially crafted requests to the Admission Controller to inject Nginx configuration (Configuration Injection). Normally, changing Nginx configuration requires high privileges to create/modify Ingress objects, but this vulnerability allows configuration injection with only Pod network access, without separate authentication or high privileges, significantly lowering the barrier for attack.

When combined with other configuration injection vulnerabilities (CVE-2025-24513, CVE-2025-24514, CVE-2025-1097, CVE-2025-1098), an attacker can use this path to steal sensitive information (e.g., Secrets) or arbitrarily manipulate Nginx's behavior.

Potential Consequences of Ignoring CVE-2025-1974

Ignoring this critical vulnerability can lead to the following severe consequences:

• Cluster Takeover: An attacker can steal Kubernetes Secrets accessible by ingress-nginx (including Secrets from all namespaces by default). This may include sensitive information like service account tokens, which can be used to gain administrator privileges over the entire cluster and completely take it over.
• Sensitive Data Leakage: Attackers can intercept traffic routed through Ingress or manipulate Nginx settings to access and leak sensitive data from internal services.
• Denial of Service: Injecting incorrect configurations can stop or cause malfunction in the ingress-nginx controller or Nginx processes, completely blocking external access to internal applications.
• Establish Internal System Penetration Path: Attackers can use stolen credentials or manipulated routing settings to establish a foothold for expanding penetration into other systems or networks within the cluster.

This vulnerability is particularly dangerous because it can be exploited with relatively low privileges (Pod network access). Please check your current ingress-nginx version immediately and upgrade to a stable version to protect your system and data.