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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.9",
  "pubDate": "2026-10-14T17:19:11.147Z",
  "pubdate": "2026-10-14T17:19:11.147Z",
  "executiveSummary": "A critical security vulnerability in KEDA (Kubernetes Event Driven Autoscaling) versions 2.20.2 and earlier allows namespace administrators to perform privilege escalation. The flaw involves the insecure handling of HashiCorp Vault authentication configurations within TriggerAuthentication resources.\nBy manipulating the hashiCorpVault.address field, an attacker can coerce the KEDA operator—which possesses high-level cluster permissions—into transmitting its projected ServiceAccount token to an attacker-controlled endpoint. This action effectively bypasses existing JWT-shape filters implemented for CVE-2025-68476.\nThe vulnerability requires the attacker to hold namespace administrator privileges, specifically the ability to create or modify ScaledObject and TriggerAuthentication resources. Successful exploitation leads to full compromise of the KEDA operator's identity, granting the attacker the operator's extensive cluster-wide read/write permissions. This presents a severe risk, as the operator typically requires broad access to cluster secrets and workload management operations. The issue is resolved in version 2.21.0.",
  "technicalDetails": "The vulnerability resides within the KEDA operator's logic for processing HashiCorp Vault authentication parameters. Specifically, when a user configures a TriggerAuthentication resource to use HashiCorp Vault, they specify an address for the Vault instance. In affected versions, the operator fails to validate this endpoint, allowing a malicious actor to supply an arbitrary, attacker-controlled URL.\nThe exploit flow initiates when a namespace administrator creates or updates a ScaledObject linked to a malicious TriggerAuthentication resource. Within this resource, the attacker sets the hashiCorpVault.address to their own server and selects Kubernetes authentication without providing explicit credentials. Upon reconciliation, the KEDA operator attempts to authenticate with the specified Vault endpoint. Because the authentication method is set to Kubernetes auth, the KEDA operator automatically injects its own projected ServiceAccount token into the login request to the attacker's server.\nThe root cause is an improper trust assumption regarding the Vault configuration and the subsequent failure to isolate the operator's identity token from user-defined parameters. While previous mitigations (CVE-2025-68476) introduced JWT-shape filtering to prevent arbitrary token relay, the filter is insufficient because it validates the token's structure—confirming it is a legitimate Kubernetes ServiceAccount token—rather than restricting the destination endpoint or the context in which the token is presented.\nOnce the attacker receives the KEDA operator's ServiceAccount token via the malicious endpoint, the token acts as a valid credential for the Kubernetes API server. Since the KEDA operator requires broad permissions—including the ability to read Secrets across namespaces and manage workload configurations—the attacker can use the stolen token to impersonate the operator. Post-exploitation impact includes unauthorized retrieval of sensitive cluster secrets, modification of existing workloads, and potential escalation to cluster-admin depending on the specific RoleBindings associated with the KEDA service account."
}