Severity: CRITICAL (CVSS 9.8) | Action required: Upgrade immediately Multiple vulnerabilities in the NGINX Ingress controller allow attackers with pod network access to execute arbitrary code and access all Secrets across the cluster -- without credentials or administrative privileges. If your ACK cluster runs NGINX Ingress controller with the admission webhook enabled, treat this as an emergency and take action now.
Am I affected?
Use the following decision tree to determine whether your cluster is at risk.
Step 1: Check whether NGINX Ingress controller is installed
kubectl get pods -n kube-system --selector app=ingress-nginxIf no pods are returned, your cluster does not have NGINX Ingress controller installed and is not affected. No further action is needed.
If pods are returned, proceed to Step 2.
Step 2: Check which version is running
Affected NGINX Ingress controller versions:
All versions earlier than v1.11.5
v1.12.0
If your cluster runs v1.11.5, v1.12.1, or any later version, you are already on a patched release. No further action is needed.
To determine your installed version, see How to check your installation method and version.
Step 3: Check whether the admission webhook is enabled
Clusters with the admission webhook disabled are not affected by the most critical vulnerability (CVE-2025-1974). However, the annotation-based injection vulnerabilities (CVE-2025-1097, CVE-2025-1098, CVE-2025-24514, CVE-2025-24513) still apply if any user has Ingress resource write permissions. You should still upgrade.
Add-ons installation: Run the following command: If the resource is not found, the admission webhook is disabled.
kubectl get validatingwebhookconfigurations ingress-nginx-admissionMarketplace installation: View the basic information of the related application and check if any resource of type
ValidatingWebhookConfigurationexists.
Summary
Condition | Risk level |
NGINX Ingress controller not installed | Not affected |
Installed, version >= v1.11.5 (1.11.x) or >= v1.12.1 (1.12.x) | Not affected (already patched) |
Installed, affected version, admission webhook disabled | Reduced risk (still upgrade) |
Installed, affected version, admission webhook enabled | Affected -- take action immediately |
How to check your installation method and version
NGINX Ingress controller can be installed in ACK clusters through two paths: the Add-ons page or the Marketplace (Helm chart). The remediation steps differ depending on which method was used.
Installed through the Add-ons page
Method 1: Check on the Add-ons page
Log on to the ACK console. In the left-side navigation pane, click Clusters.
On the Clusters page, find the cluster that you want to manage and click its name. In the left-side navigation pane, click Add-ons.
On the Add-ons page, search and locate Nginx Ingress Controller, and check on the component card whether the component is installed and its current version.
Method 2: Query using kubectl
kubectl get pods -n kube-system --selector app=ingress-nginxInstalled through the Marketplace (Helm chart)
Log on to the ACK console. In the left-side navigation pane, click Clusters.
On the Clusters page, find the cluster that you want to manage and click its name. In the left-side navigation pane, choose Applications > Helm.
In the Helm list, check if
ack-ingress-nginxorack-ingress-nginx-v1exists in the Chart Name column, where Application Version is the current version of the NGINX Ingress controller component.
Vulnerability details
The Kubernetes community has disclosed five security vulnerabilities in the NGINX Ingress controller. Four allow attackers to inject malicious configurations through crafted Ingress annotations. The most critical vulnerability, CVE-2025-1974, enables unauthenticated code execution by any entity with pod network access, bypassing the admission webhook entirely.
In practical terms, any workload running in your cluster's pod network -- or any entity with network access to the admission controller endpoint -- can exploit these vulnerabilities to execute arbitrary code within the NGINX Ingress controller and retrieve all Secrets across the cluster. In many common scenarios, the pod network is accessible to all workloads in your cloud VPC, or even to anyone connected to your corporate network. This means that Secrets such as TLS certificates, API credentials, and other sensitive data stored in Kubernetes may be exposed.
CVE ID | Severity | CVSS v3.1 score | Description | Risk | Reference |
High | Attackers with Ingress resource write permissions can exploit the | Attackers may execute arbitrary code in the NGINX Ingress controller context and further obtain Secrets across the cluster. | |||
High | Attackers with Ingress resource write permissions can exploit the | Attackers may execute arbitrary code in the NGINX Ingress controller context and further obtain Secrets across the cluster. | |||
Critical | Attackers with pod network access can bypass the admission webhook to inject configurations. | Attackers may execute arbitrary code in the NGINX Ingress controller context and further obtain Secrets across the cluster. | |||
High | Attackers with Ingress resource write permissions can exploit the | Attackers may execute arbitrary code in the NGINX Ingress controller context and further obtain Secrets across the cluster. | |||
Medium | NGINX Ingress controller fails to adequately validate or filter input data submitted by users with write permissions to Ingress resources. Attackers can exploit this vulnerability to craft malicious requests, injecting unauthorized data into the configuration file generation path. | Directory traversal vulnerabilities within the container may be triggered. This vulnerability may cause denial of service (DoS), or when combined with other vulnerabilities, lead to the leakage of limited Secrets instances in the cluster. |
Interim mitigation
If you cannot upgrade immediately, disable the admission webhook to block the most critical attack vector (CVE-2025-1974). This is a temporary measure -- you must still upgrade to a patched version as soon as possible.
For clusters with NGINX Ingress controller installed through the Add-ons page
On the Add-ons page of the target cluster, find the Nginx Ingress Controller component and manually disable the admission webhook feature. For details, see Manage NGINX Ingress controller.
For clusters with NGINX Ingress controller installed through the Marketplace
Manually delete the related admission webhook to reduce risk:
kubectl delete validatingwebhookconfigurations ingress-nginx-admissionDisabling or deleting the admission webhook removes a pre-validation mechanism for Ingress configurations. While this mitigates the vulnerability, invalid Ingress configurations will no longer be rejected before they take effect. Re-enable the admission webhook after you upgrade to a patched version.
Remediation: Upgrade to patched version
The community has fixed all five vulnerabilities in the following NGINX Ingress controller versions:
v1.11.5
v1.12.1
Upgrade to v1.11.5 or later (for the 1.11.x release line) or v1.12.1 or later (for the 1.12.x release line) during off-peak hours.
Add-on management
If you have not already done so, disable the admission webhook as described in Interim mitigation to reduce risk while you prepare the upgrade.
Upgrade the NGINX Ingress controller component to v1.11.5 or later. See NGINX Ingress controller release notes for version details, and follow the instructions in Update NGINX Ingress controller to perform the upgrade.
After the upgrade is complete, re-enable the admission webhook.
After the update is complete, make sure to re-enable the admission webhook feature. This feature serves as a pre-validation mechanism for Ingress configurations and can effectively improve service reliability and stability. Before your Ingress configuration creation or update takes effect, the admission webhook will alert you about errors in the Ingress configuration, so that you can prevent problems from occurring.
Marketplace
If you have not already done so, manually delete the admission webhook as described in Interim mitigation to reduce risk while you prepare the upgrade.
Check the component release notes on the console's Marketplace page or Helm page, and update ack-ingress-nginx on the Marketplace page to v1.11.5 or later during off-peak hours.
After the upgrade is complete, verify that the admission webhook has been re-created as part of the updated Helm chart deployment. If it has not, re-enable it manually.
Patch references
The community has addressed each vulnerability in the following commits (all part of PR #13068):
CVE | Commit |
CVE-2025-1097 | ingress-nginx main@06c992a |
CVE-2025-1098 | ingress-nginx main@2e9f373 |
CVE-2025-1974 | ingress-nginx main@0ccf4ca |
CVE-2025-24513 | ingress-nginx main@cbc1590 |
CVE-2025-24514 | ingress-nginx main@ab470eb |
FAQ
Q: My cluster does not have NGINX Ingress controller installed. Am I affected?
No. Clusters without NGINX Ingress controller installed are not affected by any of these vulnerabilities. No action is needed.
Q: I disabled the admission webhook. Am I still at risk?
Disabling the admission webhook blocks the most critical vulnerability (CVE-2025-1974, CVSS 9.8). However, the annotation-based injection vulnerabilities (CVE-2025-1097, CVE-2025-1098, CVE-2025-24514, CVE-2025-24513) can still be exploited by attackers who have Ingress resource write permissions, regardless of the webhook configuration. You should still upgrade to a patched version.
Q: Should I re-enable the admission webhook after upgrading?
Yes. The admission webhook serves as a pre-validation mechanism for Ingress configurations. It detects and rejects invalid configurations before they take effect, helping you prevent service disruptions. Always re-enable it after upgrading to a patched version.
Q: What is the difference between the Add-ons and Marketplace installation paths?
NGINX Ingress controller can be installed in ACK through the Add-ons page (managed by ACK's add-on lifecycle) or through the Marketplace as a Helm chart. The remediation steps differ slightly: Add-ons users disable the webhook through the console UI, while Marketplace users delete the ValidatingWebhookConfiguration resource directly. Both paths require upgrading to v1.11.5 or later.