On this page (7 sections)

KEDA, the Kubernetes event-driven autoscaler, has a critical privilege escalation bug tracked as CVE-2026-77524. Someone who may create KEDA TriggerAuthentication and ScaledObject resources in their own namespace can trick the KEDA operator into sending out its own ServiceAccount token, which carries cluster-wide permissions. KEDA 2.21.0 contains the fix.

If you run KEDA on a shared or multi-tenant cluster where teams hold namespace-level admin rights, treat this as a priority. Clusters where only cluster administrators can create these resources are much less exposed.

At a glance

What happened

The GitHub advisory explains that KEDA's HashiCorp Vault integration accepts an address from the TriggerAuthentication object without validating it. A namespace admin can point that address at a server they run and select Kubernetes authentication without giving any credential. In that case KEDA falls back to the operator pod's projected ServiceAccount token and submits it to the chosen address as a Vault login.

That token is the operator's own identity, and the advisory lists what it allows: reading Secrets in all namespaces, creating and deleting jobs and horizontal pod autoscalers cluster-wide, updating scale on any workload, and updating validating webhook configurations and API services. The advisory's conclusion is that this amounts to escalation from namespace admin to cluster admin in real environments.

Why the earlier fix fell short

This issue is described as an incomplete remediation of CVE-2025-68476. The earlier safeguard only checked that a file looked like a JWT whose subject starts with system:serviceaccount:. Because the operator's projected token has exactly that shape, it passed the check, and the hashiCorpVault.address field was still accepted as given.

Put simply, this is a confused-deputy situation: a powerful component can be steered by a low-privileged user into handing its credentials to a destination the user picks. The record lists CWE-269 (improper privilege management) and CWE-918 (server-side request forgery).

Who is realistically exposed

Per the advisory, the tenant needs create rights on triggerauthentications.keda.sh and scaledobjects.keda.sh in its own namespace (the documented KEDA tenant workflow), together with the built-in edit ClusterRole there. Multi-tenant setups often grant this through a broad namespaced admin Role. A default KEDA installation is affected.

  • Platform teams offering shared clusters with self-service namespaces.
  • Agencies or hosting providers running several customers on one cluster.
  • Organizations where CI service accounts or developers hold namespace admin and can create KEDA resources.
  • Clusters where KEDA is installed but nobody has reviewed who may create its custom resources.

The finder is credited as Artem Cherezov, and the advisory says the behavior was confirmed on KEDA v2.20.0 with default settings. Only one independent publisher covers the story so far, and the research contains no report of attacks in the wild. That is the absence of evidence, not proof of safety.

Dates differ between records: the GitHub advisory shows publication on Sep 23, 2026 (updated Oct 15, 2026), while the CVE record lists 2026-10-14. Neither changes the fix.

How to check your exposure

Start with the version. This read-only command prints the container image of the operator deployment. It assumes the default namespace keda and deployment name keda-operator, so adjust both if your install differs. An image tag below 2.21.0 is affected.

Show the KEDA operator image and version (run with kubectl access to the cluster)Shell
kubectl -n keda get deploy keda-operator -o jsonpath='{.spec.template.spec.containers[*].image}'

Next, list every TriggerAuthentication in the cluster and look for any you do not recognize, especially in tenant namespaces. The command is read-only and needs permission to list them across namespaces.

List all TriggerAuthentications across namespaces (read-only)Shell
kubectl get triggerauthentications.keda.sh --all-namespaces

To examine a suspicious entry, print it as YAML and check whether a hashiCorpVault address points somewhere other than your real Vault server.

Inspect one TriggerAuthentication (replace the placeholders)Shell
kubectl -n <namespace> get triggerauthentication <name> -o yaml

Finally, audit who is allowed to create these resources. Review RoleBindings that grant create on triggerauthentications.keda.sh and scaledobjects.keda.sh, including wildcard admin roles.

What to do now

Caution. Upgrading the operator restarts it and may briefly pause autoscaling decisions. Plan the change for a low-traffic window and test in a non-production cluster first.
Tip. The advisory points out that a cluster-wide Secret read can reveal tokens for more privileged accounts. If you suspect misuse, rotating those credentials matters as much as patching.

Detection and monitoring

The research gives no specific log signatures, so rely on general Kubernetes auditing. Turn on API server audit logging if it is off, then watch for TriggerAuthentication objects created or changed by non-admin identities, and for Secret reads, new jobs or validating webhook changes coming from the KEDA operator's ServiceAccount. Egress network policies that restrict where the operator pod can connect add another layer, since the attack relies on the operator reaching a tenant-controlled address.

If your cluster serves public websites or APIs, keep outside-in checks running as well. Webforta Monitor watches uptime, certificates and DNS for changes, which can help you notice side effects if cluster-level tampering ever alters what you serve. It does not detect this flaw itself. For general background, see what a WAF does.

Sources

This article is based on the public sources below. Details can change as vendors and researchers publish more; check the original advisories before acting on version numbers.

  1. CVE-2026-77524 - GitHub Advisory Databasegithub.com
  • KEDA
  • Kubernetes
  • privilege escalation
  • CVE-2026-77524
  • multi-tenant