KEDA EUVD-2026-101431

Requires KEDA 2.20.2 or earlier deployed with its default cluster-wide operator ServiceAccount, AND an attacker holding namespace-administrator privileges able to create TriggerAuthentication and ScaledObject resources in at least one namespace. The attacker must set hashiCorpVault.address to a tenant-controlled endpoint and select Kubernetes authentication with no explicit credential, causing the operator to send its projected ServiceAccount token outbound. Limiting factors: exploitation is gated by tenant-level RBAC to create those specific CRDs (not anonymous/unauthenticated), and is most impactful in multi-tenant clusters where namespace admins are untrusted relative to the cluster-scoped operator; the fix (2.21.0) adds audience enforcement and an outbound Vault-address allowlist, and the older partial fix CVE-2025-68476 does NOT block this path because its JWT-shape filter accepts the operator token.

This is a genuine high-priority issue in environments that run KEDA with HashiCorp Vault integration, not merely a high-CVSS artifact. The CVSS:3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, 9.9) is internally consistent with the description: a tenant-level namespace administrator (PR:L) can, over the Kubernetes API (AV:N) with no user interaction and low complexity, cause the KEDA operator to leak its own cluster-wide ServiceAccount token, producing a scope change (S:C) from namespace-confined privileges to cluster-wide control. The standout signal is the SSVC-style technical impact: total compromise of a cluster control-plane component (broad Secret reads, workload/admission operations), which is effectively a privilege-escalation-to-cluster-admin primitive (CWE-269). However, several key signals are MISSING: no EPSS score was provided, so exploitation probability cannot be quantified; there is no CISA KEV entry and no indication of a public POC in the supplied data, so this is not confirmed to be actively exploited or weaponized. Exploitation is also gated by a non-trivial prerequisite - the attacker must already hold namespace-admin rights sufficient to create TriggerAuthentication and ScaledObject resources - which lowers real-world mass-exploitation likelihood relative to the raw score and makes this more of an insider/multi-tenant-boundary threat than an internet-facing drive-by. Notably, this bypasses the prior CVE-2025-68476 remediation (the JWT-shape filter accepts the operator token), so partially-patched clusters remain exposed.

In a multi-tenant Kubernetes cluster, a user with namespace-administrator rights creates a TriggerAuthentication resource pointing hashiCorpVault.address at an endpoint they control and selects Kubernetes authentication with no explicit credential. The KEDA operator dutifully reads its own projected ServiceAccount token and sends it to the attacker's endpoint as a Vault login, handing the attacker the operator's cluster-wide identity and enabling cluster-wide Secret theft and workload/admission tampering. No public exploit was identified at time of analysis, but the attack is simple and deterministic once namespace-admin access exists.