External risk intelligence

KEDA Kubernetes Event Driven Autoscaling Escalation via Tenant-Controlled Vault Address

CVE advisorySeverity: CRITICAL (CVSS 9.9)

CVE-2026-77524

The vulnerability resides within KEDA, a Kubernetes-based autoscaling component. Exploitation requires the attacker to already possess namespace administrator privileges to create specific resources. This is an internal configuration issue within a cluster management tool, not a service designed for public internet exposure.

Server-Side Request Forgery

Halo Surface Signal: 2 out of 5 — less likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

A critical vulnerability exists in KEDA, a Kubernetes autoscaling tool, that could allow an attacker with specific administrative access to gain broad control over your cluster's sensitive data and operations. This issue arises from how KEDA handles authentication with external services like HashiCorp Vault, potentially exposing sensitive operator permissions.

KEDA allows attackers to steal cluster admin privileges.
Criticality: Confirms KEDA’s internal security and access controls.
Executive Takeaway: Ensure KEDA configurations are secured.

Attack Path

How an attacker could exploit the issue

An attacker with namespace administrator privileges can target the KEDA component by creating specific resources. By configuring these resources to point to a tenant-controlled endpoint and leveraging Kubernetes authentication, the attacker can trick KEDA into sending the operator pod's service account token to this endpoint. This allows the attacker to gain the operator's cluster-wide permissions, potentially leading to unauthorized access to sensitive information and system modifications.

Requires namespace administrator access.
Triggered by creating specific KEDA resources.
Leads to broad cluster-wide permissions.

Live Threat

Current exploitation, exposure, and threat context

A Kubernetes administrator with namespace privileges could configure KEDA to send a ServiceAccount token to a malicious endpoint. This token could then be used to gain cluster-wide permissions, potentially allowing unauthorized access to sensitive information and system operations.

Operator's cluster-wide permissions.
Malicious endpoint receives token.
Broad secret reads and system operations.

Operational Fix

Recommended remediation, mitigation, and detection steps

Application owners and Kubernetes platform teams are likely responsible for addressing this vulnerability. The first step is to identify all KEDA deployments, confirm their reachability and criticality, and then assign ownership for remediation planning.

Assign KEDA deployment ownership.
Verify KEDA resource reachability.
Plan for KEDA upgrade or mitigation.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is KEDA and how is it used in Kubernetes?

KEDA, or Kubernetes-based Event Driven Autoscaling, is a specialized component that automatically scales your application workloads based on external event sources like message queues or databases. It allows clusters to respond dynamically to traffic demands by adjusting pod counts, effectively bridging the gap between infrastructure scaling and application-specific event data.

What does CWE-269 and CWE-918 mean for CVE-2026-77524?

This vulnerability involves Improper Privilege Management (CWE-269) and Server-Side Request Forgery (CWE-918). Essentially, the software can be manipulated into making unauthorized requests to a destination chosen by the attacker. By directing KEDA to a controlled endpoint, the system is tricked into handing over powerful security tokens it was never intended to share with that specific destination.

How can an attacker trigger this vulnerability?

An attacker must already have namespace administrator privileges to create or modify TriggerAuthentication and ScaledObject resources. The flaw is not triggered by public traffic hitting your services; it requires an internal user to deliberately configure KEDA to point at a malicious external endpoint, causing the operator pod to unknowingly transmit its sensitive service account token.

Does my KEDA deployment face external risks?

According to Halo Surface Signal, this is primarily an internal configuration risk rather than an internet-facing threat. Because exploitation requires prior administrative access within the cluster, the risk is contained to users who are already authorized to manage KEDA resources within your specific environment, rather than anonymous actors on the public internet.

What are the first steps to secure my cluster?

You should immediately identify all KEDA instances running in your environment and prepare to upgrade them to version 2.21.0 or later. While planning the upgrade, platform teams should audit existing ScaledObject and TriggerAuthentication configurations to ensure they are not referencing unauthorized or untrusted Vault endpoints.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.