CVE-2026-77524
9.9CriticalPublished 14 Oct 2026 · NVD status: Awaiting Analysis · AI triage by gemini-3.8-flash
- Attack vector
- Network
- Complexity
- Low
- Privileges needed
- Low
- User interaction
- None
- Impact
- Full C/I/A compromise
- Weakness
- CWE-269, CWE-918
Impact
An attacker with namespace-level rights can steal KEDA's cluster-wide ServiceAccount token and escalate to full cluster privileges. They need permissions to create TriggerAuthentication and ScaledObject resources.
Root cause
When HashiCorp Vault authentication is configured without explicit credentials, KEDA sends its own operator pod ServiceAccount token to the user-specified Vault address.
Affected systems
KEDA versions 2.20.2 and earlier
CVSS v3.1 · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Fix & remediation
Upgrade KEDA to version 2.21.0. If you cannot upgrade immediately, restrict RBAC access to TriggerAuthentication and ScaledObject CRDs or use admission control to block custom hashiCorpVault.address values.
$ helm repo update && helm upgrade keda kedacore/keda --version 2.21.0 -n kedaAI-suggested. Run it in staging first and check it against the vendor advisory. Why?
NVD description
KEDA is a Kubernetes-based Event Driven Autoscaling component. In version 2.20.2 and earlier, a namespace administrator who can create TriggerAuthentication and ScaledObject resources can set hashiCorpVault.address to a tenant-controlled endpoint and select Kubernetes authentication without an explicit credential. KEDA then uses the operator pod's projected ServiceAccount token and sends it to that endpoint as a Vault login credential. The JWT-shape filter from the prior CVE-2025-68476 remediation accepts the operator token because its subject is a Kubernetes ServiceAccount, so the attacker can obtain the operator's cluster-wide permissions, including broad Secret reads and workload or admission-related operations. This vulnerability is fixed in 2.21.0.