CVE-2025-1974

What it actually does

The flaw enables unauthenticated remote code execution against the Kubernetes ingress-nginx admission/controller path when an attacker can reach the pod network or the ingress-nginx admission webhook service. By submitting crafted admission-review style requests or malicious Ingress configuration, the attacker can cause code to run in the context of the ingress-nginx controller. Because the controller commonly runs with a Kubernetes service account that can read Secrets, compromise of the controller can expose cluster credentials, TLS keys, application secrets, tokens, and other sensitive configuration. The provided affected-product metadata lists Debian ffmpeg packages and fixed versions, but that conflicts with the Kubernetes ingress-nginx description; teams should verify the authoritative vendor advisory for the exact product mapping before relying on package-only remediation.

Why it matters to the business

Successful exploitation can turn network access to the Kubernetes pod network into full compromise of ingress infrastructure and potentially cluster-wide secret disclosure. This can lead to credential theft, application takeover, lateral movement, data exposure, service disruption, and follow-on compromise of workloads that trust Kubernetes Secrets. The CVSS score is critical, EPSS is extremely high, and exploit maturity is listed as weaponized, so internet-exposed, flat, or weakly segmented Kubernetes environments should treat this as an urgent remediation item even though it is not listed in CISA KEV in the supplied data.

How an attack unfolds

An attacker first obtains network reachability to the Kubernetes pod network or specifically to the ingress-nginx controller admission service, commonly exposed internally on the webhook port. The attacker then sends a crafted admission request or Ingress object containing malicious configuration that is processed by ingress-nginx validation logic. During validation, ingress-nginx generates or tests NGINX configuration in a way that causes attacker-controlled input to be interpreted as executable behavior. The payload runs inside the ingress-nginx controller container with that controller's permissions. From there, the attacker can read the mounted service account token, query the Kubernetes API as the ingress-nginx service account, enumerate or retrieve Secrets accessible to that account, and use stolen secrets to pivot into applications, namespaces, container registries, cloud services, or other cluster components.

How to fix it

Patch the affected component using the authoritative Kubernetes ingress-nginx advisory and vendor package source. Upgrade ingress-nginx controller deployments to a fixed release and redeploy the controller pods so the vulnerable admission code is no longer running. If the supplied package inventory is applicable in your environment, Debian package metadata indicates ffmpeg fixes in 7:4.3.9-0+deb11u1 for Debian 11 and 7:7.1.1-1 for Debian 13/14; however, this package list conflicts with the Kubernetes ingress-nginx vulnerability description and should not be treated as sufficient to remediate ingress-nginx exposure. As interim mitigation, restrict network access to the ingress-nginx admission webhook so only the Kubernetes API server can reach it, enforce Kubernetes NetworkPolicies around controller and admission services, disable or remove unnecessary admission webhook exposure where operationally safe, and reduce the ingress-nginx controller service account permissions so it cannot read Secrets cluster-wide unless explicitly required. Rotate Secrets, service account tokens, TLS keys, and external credentials that may have been accessible to the controller if exploitation is suspected.

How to confirm the fix worked

Confirm the installed ingress-nginx controller image tag and Helm chart/app version match a fixed version from the official ingress-nginx advisory. Verify all old controller pods have been restarted or replaced and no vulnerable image digests remain running. Test network reachability to the admission webhook from ordinary pods; non-control-plane workloads should not be able to connect. Review RBAC for the ingress-nginx controller service account and confirm Secret access is limited to the minimum required scope. If package metadata is used for compliance validation, verify installed Debian ffmpeg versions are at or above 7:4.3.9-0+deb11u1 on Debian 11 and 7:7.1.1-1 on Debian 13/14, but separately validate ingress-nginx because the supplied product mapping is inconsistent. Run Kubernetes audit queries for unexpected direct admission webhook access, suspicious Ingress admission requests, and unusual Secret reads by the ingress-nginx service account before and after patching.

Typical attack path

1. Gain network access to the Kubernetes pod network, a compromised workload, a VPN, or another internal path that can reach ingress-nginx admission/controller services.
2. Identify the ingress-nginx admission webhook service, commonly named ingress-nginx-controller-admission or similar, and confirm the admission endpoint is reachable.
3. Send crafted AdmissionReview or Ingress validation traffic containing malicious ingress-nginx configuration or annotations.
4. Trigger the ingress-nginx controller validation path to execute attacker-controlled code inside the controller context.
5. Access the controller container environment, mounted service account token, and Kubernetes API permissions.
6. Enumerate namespaces, Ingress objects, ConfigMaps, and Secrets available to the ingress-nginx service account.
7. Exfiltrate Secrets or use them for lateral movement, application impersonation, cloud credential abuse, or persistence.
8. Optionally deploy additional payloads, modify Kubernetes resources, or create stealthy access paths before removing obvious artifacts.

How to detect it

Review Kubernetes API audit logs, ingress-nginx controller logs, admission webhook logs, container runtime events, endpoint/network telemetry, and EDR process telemetry from controller nodes. Look for direct POST requests to the ingress-nginx admission endpoint from pod IPs or non-control-plane sources, especially requests containing AdmissionReview payloads or unusual Ingress annotations. In Kubernetes audit logs, investigate spikes or unusual patterns where the ingress-nginx controller service account lists, gets, or watches Secrets, especially across many namespaces or outside normal deployment activity. In controller container telemetry, look for unexpected child processes such as shells, curl, wget, nc, python, perl, or other utilities spawned by the ingress-nginx controller or nginx validation routines. Examine recent Ingress objects and admission requests for suspicious annotations, malformed values, command separators, embedded shell syntax, file reads, or payload staging URLs. If exploitation is suspected, preserve the ingress-nginx controller pod filesystem, logs, running process list, service account token use history, and Kubernetes audit records before rotating credentials.

• ingress-nginx-controller-admission
• ingress-nginx-admission
• validate.nginx.ingress.kubernetes.io
• POST /networking/v1/ingresses
• AdmissionReview
• "kind":"AdmissionReview"
• "apiVersion":"admission.k8s.io/v1"
• system:serviceaccount:ingress-nginx:ingress-nginx
• system:serviceaccount:ingress-nginx:ingress-nginx-admission
• system:serviceaccount:ingress-nginx:ingress-nginx-controller
• /var/run/secrets/kubernetes.io/serviceaccount/token
• nginx.ingress.kubernetes.io/auth-url
• nginx.ingress.kubernetes.io/auth-tls-match-cn
• nginx.ingress.kubernetes.io/mirror-target
• nginx -t
• /bin/sh -c
• /bin/bash -c
• curl
• wget
• nc
• kubectl get secrets
• secrets?watch=true
• resource=secrets
• verb=list
• verb=get

What your security team should do

• Immediately identify all Kubernetes clusters running ingress-nginx and determine whether the admission webhook/controller is reachable from pod networks or untrusted workloads.
• Prioritize patching or upgrading ingress-nginx because exploit maturity is weaponized and EPSS is extremely high.
• Apply NetworkPolicies or equivalent controls so only the Kubernetes API server can reach ingress-nginx admission webhook services.
• Review and reduce the ingress-nginx controller service account permissions, especially cluster-wide read access to Secrets.
• Hunt for suspicious admission requests, unusual controller child processes, and unexpected Kubernetes Secret access by the ingress-nginx service account.
• If compromise is plausible, rotate Kubernetes Secrets, ingress TLS certificates, service account tokens, application credentials, and any cloud credentials stored in Secrets.
• Validate the conflicting product metadata against authoritative vendor advisories so remediation tracking does not incorrectly close Kubernetes ingress-nginx exposure based only on unrelated package updates.
• Add continuous monitoring for admission webhook exposure and privileged Kubernetes service accounts that can read Secrets across namespaces.