CVE-2025-1974 – Critical Kubernetes Ingress‑NGINX Remote Code Execution

What is CVE-2025-1974?

CVE-2025-1974 is a security flaw discovered in Kubernetes that can affect the ingress‑nginx controller. The vulnerability allows an unauthenticated attacker who can reach the pod network to execute arbitrary code inside the controller process. Because the controller typically runs with permission to read any Secret in the cluster, a successful attack can also expose those Secrets.

CISA’s confirmed actively-exploited flaws are tracked on our Known Exploited Vulnerabilities tracker, refreshed daily.

Why you should care right now

The CVSS score is 9.8 – that puts it in the critical range. If your environment runs the default ingress‑nginx installation, the controller has cluster‑wide access to Secrets. That means a single compromised pod could give an attacker the keys to the kingdom. Even if you have a custom deployment, the same code path is present, so the risk remains.

How the vulnerability works

The NVD entry only tells us that the attack requires unauthenticated network access to a pod and that the result is arbitrary code execution in the context of the ingress‑nginx controller. The exact technical details have not been published, so we can only describe the class of the flaw.

In short, the controller processes inbound traffic and configuration data from the Kubernetes API. Under certain conditions an attacker can craft network traffic that triggers a code path which does not properly validate input. The unchecked input is then executed with the controller’s privileges. Because the controller runs as a privileged service account and can read Secrets, the attacker can also pull those Secret objects from the API server.

The vulnerability is not tied to a specific version number in the public data – the NVD has not released a list of affected releases. That means you cannot rely on a version check alone; you need to verify whether the component you run is covered by the fix.

Is your cluster vulnerable?

First, confirm you are actually using the ingress‑nginx controller. Run:

kubectl get pods -A -l app.kubernetes.io/name=ingress-nginx

If you see one or more pods, you are using it. Next, check how the controller is exposed. If the service type is LoadBalancer or NodePort, the pod network is reachable from outside the cluster. Use:

kubectl get svc -A -l app.kubernetes.io/name=ingress-nginx -o wide

Look for external IPs or node ports. If the controller is only reachable via an internal ClusterIP and you have network policies that block traffic from untrusted pods, the immediate attack surface is reduced, but not eliminated – any compromised pod inside the cluster could still reach it.

Finally, verify the service account the controller runs under and its permissions. The default installation uses the ingress-nginx service account, which typically has a ClusterRole granting get access to all Secrets. Check with:

kubectl describe serviceaccount ingress-nginx -n ingress-nginx

and

kubectl get clusterrolebinding -o yaml | grep -A5 ingress-nginx

If you see a binding that includes secrets or */*, the controller can read any Secret.

Mitigation and remediation

The definitive fix is to upgrade the ingress‑nginx controller to a release that contains the patch. The exact versions are listed in the table below – refer to it and upgrade to the patched release for your branch.

Upgrade steps depend on how you installed the controller. The most common method is via Helm. If you used Helm, run:

helm repo update
helm upgrade ingress-nginx ingress-nginx/ingress-nginx \
--namespace ingress-nginx \
--set controller.image.tag=<>

Replace <> with the tag shown in the table. If you applied a static manifest, download the latest manifest from the official source and re‑apply it:

curl -Lo ingress-nginx.yaml https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/cloud/deploy.yaml
kubectl apply -f ingress-nginx.yaml

After the upgrade, restart the pods to be sure the new image is running:

kubectl rollout restart deployment ingress-nginx-controller -n ingress-nginx

Verify the new image is in use:

kubectl get pods -n ingress-nginx -o jsonpath='{.items[*].spec.containers[0].image}'

When the image matches the patched tag, you are protected.

If a patch is not yet available for your setup

Sometimes you run a custom build or a fork that is not covered by the official releases. In that case you have three short‑term options:

• Network isolation: Use a NetworkPolicy that blocks all traffic to the ingress‑nginx controller except from trusted namespaces or IP ranges. Example:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: restrict-ingress-nginx
namespace: ingress-nginx
spec:
podSelector:
matchLabels:
app.kubernetes.io/name: ingress-nginx
ingress:
- from:
- namespaceSelector:
matchLabels:
name: trusted-namespace

• Service exposure reduction: Change the Service type from LoadBalancer or NodePort to ClusterIP and place an external load balancer or Ingress that does not forward traffic directly to the controller pods.
• Least‑privilege service account: Create a dedicated ServiceAccount for the controller that only has permission to read the Secrets it truly needs. Bind it with a Role that limits secrets to a specific namespace.

These measures do not remove the vulnerability, but they raise the bar for an attacker and buy you time until a patched release can be applied.

Verification after remediation

Once you have applied the upgrade or the temporary mitigations, run the same checks you performed earlier. Confirm the controller pods are using the patched image and that any NetworkPolicy or Service changes are in effect. You can also scan the cluster with your favourite scanner to see that CVE-2025-1974 is now reported as fixed.

If the scanner still flags the issue, double‑check that you are looking at the correct namespace and that no older pods are lingering. A quick way to purge old pods is:

kubectl delete pod -l app.kubernetes.io/name=ingress-nginx -n ingress-nginx

Kubernetes will recreate them with the new image.

Key take‑aways

• The flaw allows unauthenticated code execution inside the ingress‑nginx controller.
• Because the controller can read any Secret, the impact can be severe.
• There is no public list of affected versions – rely on the table below for the patched releases.
• Upgrade to the patched release for your branch as soon as possible.
• If you cannot upgrade immediately, isolate the controller with NetworkPolicy, limit its Service exposure, and tighten its service‑account permissions.

Stay alert, apply the fix, and verify your environment. The table below will keep you up to date on which releases contain the patch.

Affected versions

NVD has not published machine-readable version ranges for CVE-2025-1974 yet. Check the vendor advisory for the exact affected and fixed releases before you plan an upgrade.