KEDA TriggerAuthentication Flaw Allows Namespace Admins to Hijack the Operator's Cluster-Admin Token (CVE-2026-77524)

What happened

A newly published GitHub Security Advisory (GHSA-637c-6jxx-4rwm, CVE-2026-77524, CVSS 9.9) describes a privilege-escalation flaw in KEDA (tested against v2.20.0, the latest release at audit time). According to the advisory, a tenant who only holds namespace-admin rights can create a TriggerAuthentication pointing hashiCorpVault.address at a server they control, then reference it from a ScaledObject. The KEDA operator reconciles the scaler and sends its own cluster-privileged ServiceAccount token to that attacker-controlled endpoint as part of the Vault login flow, allowing the tenant to capture it. The advisory states this is an incomplete fix of a prior CVE (CVE-2025-68476): the earlier patch only validated that the loaded credential looks like a Kubernetes ServiceAccount JWT, a check the operator's own token trivially satisfies.

A public proof-of-concept is included in the advisory, and the finder reports the operator's ServiceAccount carries wildcard get across all resources cluster-wide, plus create/delete on batch/jobs and horizontalpodautoscalers, update on */scale, and update rights on validatingwebhookconfigurations and apiservices.

Why it matters

This affects any multi-tenant Kubernetes environment running KEDA with default settings where tenants are granted the documented workflow permissions (create on triggerauthentications.keda.sh/scaledobjects.keda.sh, typically via a namespaced edit-equivalent role). Per the advisory's PoC, capturing the operator's token is sufficient to read every Secret in every namespace — which can itself yield credentials for still more privileged ServiceAccounts — and to create Jobs in any namespace whose Pod Security Admission policy permits it, including PSA-exempt namespaces like kube-system. That combination is described as a practical path from namespace-admin to cluster-admin, which undermines the isolation assumptions most multi-tenant clusters rely on.

What defenders should do now

• Inventory whether KEDA is deployed in any multi-tenant cluster and whether tenants can create TriggerAuthentication or ScaledObject resources in their own namespaces.
• Review the KEDA operator's ServiceAccount permissions and consider whether the broad cluster-wide grants described in the advisory are actually required in your environment; scope them down where possible.
• Watch for TriggerAuthentication objects referencing a hashiCorpVault.address that doesn't match your known, trusted Vault endpoint(s) — this is the primitive the advisory describes as unvalidated.
• Audit outbound network connections from KEDA operator pods for traffic to unexpected in-cluster or external destinations around the time new ScaledObject/TriggerAuthentication resources are created.
• Check for anomalous use of the KEDA operator's identity (system:serviceaccount:keda:keda-operator or your equivalent) performing Secret reads or Job creation outside the keda namespace.
• Track vendor guidance from the KEDA project for a patched release and apply it once available; in the meantime, restrict who can create KEDA custom resources in shared clusters.

Developing intel

This write-up reflects only what is stated in the GitHub Security Advisory as of publication; there is no confirmed vendor patch referenced in the advisory text provided here, and details may evolve. We have not independently verified the proof-of-concept. For the full technical writeup, reproduction steps, and any updates, see the original advisory: GHSA-637c-6jxx-4rwm.