GPU VulnDB

Database/Container, Kubernetes & orchestration

KEDA: unvalidated service account token path in TriggerAuthentication reads any file from the KEDA pod

CVSS 8.2CVE-2025-68476Container, Kubernetes & orchestrationcurated

Impact

The path given in spec.hashiCorpVault.credential.serviceAccount is loaded without proper validation, so it can point anywhere in the KEDA operator pod's filesystem. The file contents are then sent to the Vault address configured in the same TriggerAuthentication, which the attacker also controls - the read turns straight into exfiltration to an external server. Anyone who can create or edit a TriggerAuthentication gets the KEDA pod's mounted secrets, its own ServiceAccount token, and any host paths the pod mounts. On a GPU cluster KEDA typically holds credentials for the queue or metrics backends that drive inference autoscaling, so this is a credential-theft path into the scaling control plane rather than into the GPUs themselves.

Who can reach it

Authenticated Kubernetes user with permission to create or modify TriggerAuthentication (or ClusterTriggerAuthentication) objects. Requires outbound network from the KEDA pod to the attacker's host.

What to do

Upgrade KEDA to 2.17.3 or 2.18.3 and roll the operator deployment - a pod restart of keda-operator, no node drain and no interruption to running workloads. Until then, restrict RBAC on TriggerAuthentication objects and audit existing ones for serviceAccount paths outside /var/run/secrets.

References

Related entries

All Container, Kubernetes & orchestration entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.