KEDA 2.21.0 Patch Fixes Critical Privilege Escalation Flaw
A critical flaw in KEDA allows namespace admins to steal cluster-wide permissions. Version 2.21.0 provides the fix for affected Kubernetes environments.

Key points
- CVE-2026-77524 is rated critical with a CVSS score of 9.9.
- The vulnerability affects KEDA versions 2.20.2 and earlier.
- A fix is available in the newly released version 2.21.0.
Kubernetes Event Driven Autoscaling (KEDA) version 2.21.0 addresses a critical security flaw that allowed namespace administrators to escalate privileges. The vulnerability, tracked as CVE-2026-77524, carries a CVSS score of 9.9. It affects all KEDA versions up to and including 2.20.2. Organizations running these older versions must update immediately to prevent unauthorized access to cluster-wide resources and sensitive secrets.
How it unfolded
- A critical flaw was identified in KEDA versions 2.20.2 and earlier.
- The issue involves improper handling of authentication tokens within the autoscaling component.
- Vendor released version 2.21.0 to patch the vulnerability CVE-2026-77524.
Who is affected
The National Vulnerability Database records that KEDA versions prior to 2.21.0 are vulnerable. Specifically, version 2.20.2 and any earlier release are at risk. The flaw stems from weaknesses classified as CWE-269 and CWE-918. In this scenario, a namespace administrator can create specific resources, including TriggerAuthentication and ScaledObject objects. By configuring these resources to point to a tenant-controlled endpoint for HashiCorp Vault, the attacker manipulates the authentication flow. The system uses the operator pod’s projected ServiceAccount token without requiring explicit credentials from the user.
Our take on the response
The vendor has provided a clear remediation path by releasing version 2.21.0. The previous mitigation attempt for CVE-2025-68476 included a JWT-shape filter, but this filter inadvertently accepted the operator token because its subject was a Kubernetes ServiceAccount. This allowed the attacker to obtain cluster-wide permissions, including broad Secret reads and workload operations. The new release corrects this logic error. That suggests the vendor is addressing the root cause of the token validation failure rather than applying another superficial filter.
Who needs to act first
Managed service providers should prioritize updating customer environments that expose KEDA to untrusted namespace administrators. Teams usually begin by identifying clusters running versions prior to 2.21.0. Before rolling out the update, verify that the new version is compatible with existing workloads. It is prudent to back up current configurations and state before applying changes. If immediate patching is not possible, restrict the ability of namespace admins to create TriggerAuthentication and ScaledObject resources. Monitor for unusual authentication requests to external endpoints as a temporary mitigation strategy.
What to do and how to stay safe: KEDA
- Check your inventory for any instances of KEDA version 2.20.2 or older.
- Plan the deployment of KEDA 2.21.0 to patch CVE-2026-77524.
- Review namespace administrator permissions to limit creation of TriggerAuthentication resources.
- Monitor logs for unauthorized attempts to access the operator’s ServiceAccount token.
Step-by-step guide: Vulnerability Prioritization: How to Rank Risks Without Wasting Time
General security guidance from the Patch Observer newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
Which versions of KEDA are vulnerable to this flaw?
All versions of KEDA prior to 2.21.0, including version 2.20.2, are affected.
Is there a fix available for CVE-2026-77524?
Yes, the vulnerability is fixed in KEDA version 2.21.0.
What permissions can an attacker gain through this exploit?
An attacker can obtain the operator's cluster-wide permissions, including broad Secret reads.



