Kubernetes Ingress NGINX Controller vulnerabilities

Details of the CVEs:

• CVE-2025-1974 (CVSS score: 9.8) – An unauthenticated attacker with access to the pod network can achieve arbitrary code execution in the context of the ingress-nginx controller under certain conditions
• CVE-2025-24514 (CVSS score: 8.8) – The auth-url Ingress annotation can be used to inject configuration into NGINX, resulting in arbitrary code execution in the context of the ingress-nginx controller and disclosure of secrets accessible to the controller
• CVE-2025-1097 (CVSS score: 8.8) – The auth-tls-match-cn Ingress annotation can be used to inject configuration into NGINX, resulting in arbitrary code execution in the context of the ingress-nginx controller and disclosure of secrets accessible to the controller
• CVE-2025-1098 (CVSS score: 8.8) – The mirror-target and mirror-host Ingress annotations can be used to inject arbitrary configuration into NGINX, resulting in arbitrary code execution in the context of the ingress-nginx controller and disclosure of secrets accessible to the controller
• CVE-2025-24513 (CVSS score: 4.8) – An improper input validation vulnerability that could result in directory traversal within the container, leading to denial-of-service (DoS) or limited disclosure of secret objects from the cluster when combined with other vulnerabilities

Mitigation

For mitigating CVE-2025-1974 on Cloudera Data Engineering on cloud, refer to the information below.

Mitigation of CVE-2025-24514, CVE-2025-1097, CVE-2025-1098, and CVE-2025-24513 is secondary to the previous CVE. They require no immediate action, as attackers can only exploit these with direct access to cluster hosts and privileges to create arbitrary ingress objects via the Kubernetes API.

Instructions

Cloudera Data Engineering does not enable the Validating Admission Controller feature of ingress-nginx and so is not exposed to the Remote Code Execution (RCE) vulnerability.

However, you can update the version of the ingress-nginx controller nevertheless by following the below mitigation steps.

1. Check your current Cloudera Data Engineering version
   1. In Cloudera Management Console, open “Data Engineering”
   2. In the left pane, click on the "Administrator" link, to list all the deployed Services.
   3. On the service card, click on the “Service Details” for the specific Service you want to mitigate:

      

2. Retrieve your cluster id from the Cloudera Data Engineering on cloud UI

   Get the cluster-id of the service as shown in the below image. The id is the 8 character long alphanumerical string after “cluster-”.

   

3. Download kubeconfig
   1. In the Cloudera Data Engineering UI, go to Administration.
   2. Select the service from the list, and in the Actions menu (3 vertical dots) select Download kubeconfig:

      

4. Patch the ingress-nginx controller image
   1. Substitute the below command with your 8 character long alpha numerical cluster id string from Step #2.

      export CLUSTER_ID=<8 character alphanumeric cluster id>

   2. Set your kubeconfig to the kubeconfig downloaded in Step #3.

      export KUBECONFIG=<kubeconfig_path>

5. Update nginx controller image to the verified patched version.

   kubectl set image deployment dex-base-nginx-${CLUSTER_ID}-controller -n dex-base-${CLUSTER_ID} controller=https://www.google.com/url?q=http://container.repository.cloudera.com/cloudera_thirdparty/hardened/ingress-nginx-controller:1.11.5-r0-202503251929

6. Verify the patch
   1. Verify the version of the nginx controller image is set to the correct version:

      kubectl --kubeconfig kubeconfig.yaml -n dex-base-${CLUSTER_ID} get deployment dex-base-nginx-${CLUSTER_ID}-controller -o jsonpath='{.spec.template.spec.containers[?(@.name=="controller")].image}'

   2. Verify that regular operations (submitting jobs, creating a new virtual cluster, etc.) work after the patch has been applied.