GHSA-637c-6jxx-4rwm KEDA: Privilege escalation from namespace admin to cluster admin via KEDA TriggerAuthentication

• Go github.com/kedacore/keda: <= 1.5.0 (no fix yet) • Go github.com/kedacore/keda/v2: < 2.21.0 → fixed in 2.21.0

Summary A namespace admin who creates a `TriggerAuthentication` and a `ScaledObject` in their own namespace can make the KEDA operator send its own ServiceAccount token to a tenant-controlled URL. That token holds `["*"]/["*"] get` cluster-wide, so it reads every Secret in every namespace, plus `batch/jobs` and `horizontalpodautoscalers` create/delete cluster-wide, `*/scale` update on any workload, `validatingwebhookconfigurations` update (rewrite or disable cluster admission), and `apiservices` update (hijack aggregated API routing). This is effectively privilege escalation from namespace admin to cluster admin in real environments: a cluster-wide Secret read alone is enough to find a token for a more privileged ServiceAccount, and the cluster-wide `batch/jobs` create lets the attacker run a workload in any namespace whose Pod Security Admission level permits it (or that is PSA-exempt, such as `kube-system` , `kyverno`) to reach the node filesystem and a control-plane kubeconfig. This is an incomplete fix of CVE-2025-68476: its content filter only requires the loaded file to be a JWT whose subject begins with `system:serviceaccount:`, which the operator's own projected token satisfies by construction. The destination field `hashiCorpVault.address` is unvalidated. Finder credits: Artem Cherezov @cherez0ff, with Claude Opus 4.8 Verified live kind v1.31.2, kedacore/keda v2.20.0 (latest at the time of audit, ) installed from the unmodified release manifest `keda-2.20.0.yaml` (`ghcr.io/kedacore/keda:2.20.0`), default settings. Preconditions 1. The tenant holds `create` on `triggerauthentications.keda.sh` and `scaledobjects.keda.sh` in its own namespace (the documented KEDA tenant workflow), plus the built-in `edit` ClusterRole in that namespace. Often granted by a namespaced admin Role (`--verb='*' --resource='*.*'`) in multi-tenant environments. 2. KEDA is installed with default settings. Reproduction Cluster preparation (not part of the attack) ```sh kind create cluster --image kindest/node:v1.31.2 --name keda-poc --kubeconfig ./kubeconfig export KUBECONFIG=./kubeconfig Install KEDA v2.20.0 (unmodified vendor release manifest). curl -sSL -o keda-2.20.0.yaml https://github.com/kedacore/keda/releases/download/v2.20.0/keda-2.20.0.yaml kubectl apply --server-side -f keda-2.20.0.yaml kubectl wait --for=condition=Established crd/triggerauthentications.keda.sh crd/scaledobjects.keda.sh --timeout=120s kubectl -n keda rollout status deploy/keda-operator --timeout=180s Tenant identity: namespace admin in tenant-a. kubectl create namespace tenant-a kubectl -n tenant-a create serviceaccount tenant kubectl -n tenant-a create rolebinding tenant-edit --clusterrole=edit --serviceaccount=tenant-a:tenant kubectl -n tenant-a create role tenant-keda --verb=create,get --resource=triggerauthentications.keda.sh,scaledobjects.keda.sh kubectl -n tenant-a create rolebinding tenant-keda --role=tenant-keda --serviceaccount=tenant-a:tenant Mint a tenant kubeconfig from a real TokenRequest token. SERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}') CA=$(kubectl config view --minify --raw -o jsonpath='{.clusters[0].cluster.certificate-authority-data}') TOKEN=$(kubectl -n tenant-a create token tenant --duration=24h) cat > kubeconfig-tenant …