Summary
KEDA can be induced to send the operator pod's projected Kubernetes ServiceAccount token to a tenant-controlled HashiCorp Vault endpoint during Kubernetes authentication. A namespace administrator who can create TriggerAuthentication and ScaledObject resources may therefore obtain a highly privileged token and use it to access cluster resources or perform administrative operations.
KEDA can be induced to send the operator pod's projected Kubernetes ServiceAccount token to a tenant-controlled HashiCorp Vault endpoint during Kubernetes authentication. A namespace administrator who can create TriggerAuthentication and ScaledObject resources may therefore obtain a highly privileged token and use it to access cluster resources or perform administrative operations.
Affected context
The vulnerability occurs in KEDA deployments that allow namespace administrators to create TriggerAuthentication and ScaledObject resources using the HashiCorp Vault integration. Risk arises when the configured Vault address can point to an attacker-controlled endpoint and Kubernetes authentication is selected without an explicitly supplied credential. In that situation, the KEDA operator may treat its own projected ServiceAccount token as a Vault login credential and disclose it to the configured endpoint.
The vulnerability occurs in KEDA deployments that allow namespace administrators to create TriggerAuthentication and ScaledObject resources using the HashiCorp Vault integration. Risk arises when the configured Vault address can point to an attacker-controlled endpoint and Kubernetes authentication is selected without an explicitly supplied credential. In that situation, the KEDA operator may treat its own projected ServiceAccount token as a Vault login credential and disclose it to the configured endpoint.
Exploit preconditions
- Attack surface: KEDA's TriggerAuthentication and ScaledObject resource configuration
- Required access: Permission to create or modify these resources within a namespace
- Trigger point: KEDA processing a Vault-backed authentication configuration
- Required configuration: A tenant-controlled Vault address combined with Kubernetes authentication that relies on the operator token
- Why exploitation is possible: The endpoint is insufficiently constrained, while token-shape validation accepts the operator's Kubernetes ServiceAccount JWT
- Attack surface: KEDA's TriggerAuthentication and ScaledObject resource configuration
- Required access: Permission to create or modify these resources within a namespace
- Trigger point: KEDA processing a Vault-backed authentication configuration
- Required configuration: A tenant-controlled Vault address combined with Kubernetes authentication that relies on the operator token
- Why exploitation is possible: The endpoint is insufficiently constrained, while token-shape validation accepts the operator's Kubernetes ServiceAccount JWT
Why this happens
The underlying issue combines insufficient control over an externally contacted authentication endpoint with excessive trust in an automatically selected credential. KEDA can use the operator pod's projected ServiceAccount token when processing a tenant-controlled Vault configuration, and the token filter does not distinguish a permitted application credential from a highly privileged operator identity. This maps primarily to CWE-269: Improper Privilege Management, because a lower-privileged namespace administrator can cause use or disclosure of a more privileged identity. It also relates to CWE-918: Server-Side Request Forgery, because attacker-controlled configuration determines the destination to which the operator sends sensitive authentication material.
The underlying issue combines insufficient control over an externally contacted authentication endpoint with excessive trust in an automatically selected credential. KEDA can use the operator pod's projected ServiceAccount token when processing a tenant-controlled Vault configuration, and the token filter does not distinguish a permitted application credential from a highly privileged operator identity. This maps primarily to CWE-269: Improper Privilege Management, because a lower-privileged namespace administrator can cause use or disclosure of a more privileged identity. It also relates to CWE-918: Server-Side Request Forgery, because attacker-controlled configuration determines the destination to which the operator sends sensitive authentication material.
Potential impact
- An attacker may obtain the KEDA operator's ServiceAccount token.
- The stolen token could allow broad reads of Kubernetes Secrets.
- An attacker could perform workload-management or admission-related operations.
- The compromise could enable namespace expansion, cluster-wide privilege escalation, or persistence.
- Sensitive credentials and application configuration may be exposed.
- An attacker may obtain the KEDA operator's ServiceAccount token.
- The stolen token could allow broad reads of Kubernetes Secrets.
- An attacker could perform workload-management or admission-related operations.
- The compromise could enable namespace expansion, cluster-wide privilege escalation, or persistence.
- Sensitive credentials and application configuration may be exposed.
General mitigation guidance
Mitigation generally focuses on preventing tenant-controlled configuration from selecting arbitrary authentication destinations or privileged operator credentials.
Common defensive patterns include:
- Allowlisting Vault endpoints and rejecting tenant-controlled or unexpected destinations.
- Requiring explicitly scoped, purpose-bound credentials for external authentication integrations.
- Preventing automatic fallback to the operator ServiceAccount token for tenant-defined configurations.
- Applying strict schema, destination, and authentication-mode validation before any outbound request.
- Restricting who can create TriggerAuthentication and ScaledObject resources.
- Running the operator with the minimum Kubernetes permissions required for its functions.
- Limiting ServiceAccount token projection, lifetime, and audience where supported.
- Enforcing network egress policies so the operator cannot contact unapproved endpoints.
Mitigation generally focuses on preventing tenant-controlled configuration from selecting arbitrary authentication destinations or privileged operator credentials.
Common defensive patterns include:
- Allowlisting Vault endpoints and rejecting tenant-controlled or unexpected destinations.
- Requiring explicitly scoped, purpose-bound credentials for external authentication integrations.
- Preventing automatic fallback to the operator ServiceAccount token for tenant-defined configurations.
- Applying strict schema, destination, and authentication-mode validation before any outbound request.
- Restricting who can create TriggerAuthentication and ScaledObject resources.
- Running the operator with the minimum Kubernetes permissions required for its functions.
- Limiting ServiceAccount token projection, lifetime, and audience where supported.
- Enforcing network egress policies so the operator cannot contact unapproved endpoints.
How teams detect issues like this
Detection approaches can include:
- Static analysis and code review checks for outbound requests whose destinations derive from tenant-controlled resource fields.
- Rules identifying authentication integrations that automatically reuse operator ServiceAccount tokens.
- Policy enforcement that allowlists external authentication endpoints and disallows arbitrary Vault addresses.
- Kubernetes audit-log monitoring for unusual TriggerAuthentication or ScaledObject creation and modification.
- Network monitoring for operator traffic to unapproved destinations or endpoints receiving JWT-shaped data.
- Permission analysis to identify namespace principals able to create these resources and review the operator's effective RBAC scope.
Detection approaches can include:
- Static analysis and code review checks for outbound requests whose destinations derive from tenant-controlled resource fields.
- Rules identifying authentication integrations that automatically reuse operator ServiceAccount tokens.
- Policy enforcement that allowlists external authentication endpoints and disallows arbitrary Vault addresses.
- Kubernetes audit-log monitoring for unusual TriggerAuthentication or ScaledObject creation and modification.
- Network monitoring for operator traffic to unapproved destinations or endpoints receiving JWT-shaped data.
- Permission analysis to identify namespace principals able to create these resources and review the operator's effective RBAC scope.
