KEDA: namespace admin can exfiltrate the operator ServiceAccount token to a tenant-controlled Vault address

Impact

A tenant who only holds namespaced rights to create ScaledObject and TriggerAuthentication objects can point hashiCorpVault.address at an endpoint they control and select Kubernetes auth with no explicit credential. KEDA then sends the operator pod's projected ServiceAccount token to that endpoint as a login credential, handing the tenant the KEDA operator's cluster-wide permissions, which include broad Secret reads and workload or admission-related operations. On a multi-tenant GPU cluster that is a straight namespace-to-cluster escalation: the stolen identity reads registry pull secrets, model-store credentials and any other Secret in the cluster, and can manipulate workloads across tenants. The JWT-shape filter added for CVE-2025-68476 does not stop it, because the operator token's subject is itself a Kubernetes ServiceAccount. Autoscaling of inference deployments is exactly the use case KEDA is installed for, so the vulnerable path is usually enabled on these clusters.

Who can reach it

Authenticated namespace administrator (or any tenant RBAC that permits creating ScaledObject and TriggerAuthentication in their own namespace) plus an attacker-reachable HTTP endpoint for the token to be sent to. No cluster-admin rights and no node access required.

What to do

Upgrade KEDA to 2.21.0. That is a control-plane component upgrade - roll the keda-operator and metrics-adapter Deployments; no GPU node drain or reboot is needed and running workloads are unaffected beyond a brief pause in autoscaling decisions. Until the upgrade lands, restrict who can create TriggerAuthentication/ClusterTriggerAuthentication via RBAC or admission policy, and treat the operator's ServiceAccount token as compromised on any cluster where tenant-authored trigger auth has been permitted.

References

Related entries

• Helm: Improper certificate validation allows unauthorized clients to connect to TillerCVE-2019-1010275 · HelmCritical
• Docker / moby: Code injection into `docker cp` via nsswitch loading a library from the container chrootCVE-2019-14271 · Docker / mobyCritical
• Helm: Malicious chart includes sensitive host content such as /etc/passwd, or triggers DoS, when loadedCVE-2019-18658 · HelmCritical
• Envoy: HTTP/2 request writes to the heap outside request buffers when the upstream is HTTP/1CVE-2019-18801 · EnvoyCritical
• Envoy: Header whitespace handling enables request smuggling and authorization bypassCVE-2019-18802 · EnvoyCritical
• Firecracker: vsock buffer overflow producing potentially exploitable crashesCVE-2019-18960 · FirecrackerCritical