How to Mitigate Risk for NGINX Ingress Controller Vulnerabilities Affecting Mirantis Kubernetes Engine

On March 24, 2025, five CVEs relating to the NGINX ingress controller (ingress-nginx) were made public: CVE-2025-1974, CVE-2025-24513,CVE-2025-1097, CVE-2025-1098, and CVE-2025-24514. Upon successful exploitation of these CVEs, known collectively as "IngressNightmare," remote code execution and theft of secrets can be perpetrated on compromised Kubernetes clusters.

At the heart of this set of CVEs is the failure of the NGINX ingress admission controller to safely apply the value of annotations, thereby permitting carefully crafted annotation values to perform unauthorized actions within the context of its process. This includes potential unauthorized code execution and access to data available to the process.

Is Mirantis Kubernetes Engine Vulnerable?

Mirantis Kubernetes Engine (MKE) versions on or before 3.7.20 and 3.8.3 ship with affected versions of the ingress-nginx component.  Users on these MKE versions are at risk of having deployed a vulnerable version of the ingress controller, but depending on the environment clusters, may not necessarily be impacted.

In order for your MKE clusters to be vulnerable, all of the following conditions must be met:

• The MKE version in use must be <= 3.7.20, <= 3.8.3, or any 3.5 and 3.6 (now EOL) versions

• ingress-nginx must be enabled in your MKE cluster, causing the installation of the ingress-nginx component)

To determine if ingress-nginx is enabled on your cluster, you can employ any of the following checks:

• Run kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginxusing MKE client bundle returns results

• Check if MKE NGINX Ingress Controller is enabled in the MKE UI:

  • Log in to the MKE web UI as an administrator.

  • Using the left-side navigation panel, navigate to > Admin Settings > Ingress.

  • In the Kubernetes tab, check if the toggle HTTP Ingress Controller for Kubernetes is on/off

• Check if cluster_config.ingress_controller configuration parameter enabled is set to true in the MKE Configuration File

If any of these checks confirms that ingress-nginx is enabled on your cluster, then you should take immediate action to mitigate the potential for attack.

Mitigating Risk of Attacks

Once you have determined that your deployment is vulnerable, the safest way to mitigate the risk of attack prior to the availability of a fully patched MKE release is to disable the version of ingress-nginx that is shipped with MKE and replace it with a patched version of ingress-nginx. By replacing this component, you can be ensured that affected unpatched code will not execute in your environment and safeguard the integrity of your cluster.

Due to the reconciler in MKE, it is not possible to apply persistent custom reconfiguration to the MKE-provided NGINX Ingress Controller to attempt mitigation. Instead, applying a patched version of the controller is reliable and avoids any risk of the affected code executing.

Disable the MKE Provided Ingress Controller

⚠IMPORTANT! While performing these steps, your NGINX Ingress Controller will be unavailable during the period after it is disabled before the replacement is installed. Inbound connections to your cluster may not arrive at running services as expected.

Ensure that these steps are performed at a time when consequences of this impact are minimal.

👉NOTE: Disabling the MKE-provided NGINX Ingress Controller will not cause the removal of Ingress Kubernetes Objects. They will continue to exist regardless of the controller’s configuration, so there is no cause for alarm when these objects remain after disabling the controller.

The first step of mitigation is to disable the MKE-provided ingress controller. You can disable the admission controller component by taking any of the following actions:

1. Disable the NGINX Ingress Controller using the MKE UI:

   1. Log in to the MKE web UI as an administrator.

   2. Using the left-side navigation panel, navigate to > Admin Settings > Ingress.

   3. In the Kubernetes tab, toggle the HTTP Ingress Controller for Kubernetes slider to the left (the text should become grey).

   4. Click Save.

2. Disable NGINX Ingress Controller using the MKE Configuration File:

   1. As an MKE admin, follow https://docs.mirantis.com/mke/3.8/ops/administer-cluster/configure-an-mke-cluster/use-an-mke-configuration-file.html#modify-an-existing-mke-configuration to get/modify the current MKE Configuration File

   2. Make sure the cluster_config.ingress_controller configuration parameter enabled is set to false

   Install a Patched Replacement Controller

   If your cluster previously had the NGINX Ingress Controller enabled, but the functionality is not required in your environment, then you can safely skip this step.

   If you do require NGINX Ingress Controller functionality in your cluster, you will need to install an alternate ingress controller until Mirantis releases a fully remediated MKE version. Mirantis recommends the patched NGINX Ingress Controller release v1.11.5 for both MKE 3.7 and MKE 3.8 deployments, available at https://kubernetes.github.io/ingress-nginx/.

   Execute the following steps to install the alternate patched NGINX Ingress Controller after you have disabled the MKE provided controller:

   1. Download and configure the MKE Client Bundle.

   2. Follow the instructions in https://kubernetes.github.io/ingress-nginx/deploy/ and install NGINX Ingress Controller, for example:
      

      helm upgrade --install ingress-nginx ingress-nginx \
          --repo https://kubernetes.github.io/ingress-nginx \
          --namespace ingress-nginx --create-namespace

👉NOTE: Because the Kubernetes objects remain after disabling the MKE provided ingress-nginx, no reconfiguration is required of the newly installed ingress-nginx. The new controller will continue to consume the previous configuration settings.

Detecting Intrusion

If you would like to check if your environment may have been subjected to compromise using this exploit, you can conduct checks on the affected ingress related annotations in your cluster. Because MKE does not apply configurations to these annotations, any values must have been applied by an external entity.

By default, MKE doesn’t add any annotations to ingress resources. Carefully review the auth-tls-match-cn, mirror-target, mirror-host, and auth-url ingress resource annotations for any values that have not been applied by you or your organization.  Any unexpected and/or suspicious values in these annotations could indicate an attempt to exploit this vulnerability.

MKE-Provided NGINX Ingress Controller Fix

While you can immediately mitigate the risk of attack to your environment using the instructions above, Mirantis is also preparing an MKE patch to provide an out-of-the-box remediation for clusters.

MKE versions 3.7.21 and 3.8.4, which contain the patched code, are presently undergoing our usual rigorous validation process prior to general availability. Specific information about this CVE remediation will be associated with MKE-12218 in the release notes accompanying the software.

In the meantime, you can rest assured that having followed the instructions in this posting that your environment is secure against intrusion from this exploit!