CVE-2025-68476: KEDA File Read Vulnerability

CVE-2025-68476 Overview

CVE-2025-68476 is an arbitrary file read vulnerability in Kubernetes Event-Driven Autoscaling (KEDA), a Kubernetes-based autoscaling component. The flaw affects any KEDA resource that uses TriggerAuthentication to configure HashiCorp Vault authentication. It stems from insufficient path validation when loading the Service Account Token specified in spec.hashiCorpVault.credential.serviceAccount. An attacker with permissions to create or modify a TriggerAuthentication resource can exfiltrate the contents of any file on the node hosting the KEDA pod. The issue was patched in versions 2.17.3 and 2.18.3.

Critical Impact

Attackers can exfiltrate sensitive files such as /etc/passwd, secrets, and cryptographic keys from the node filesystem where the KEDA pod resides by redirecting file contents to an attacker-controlled Vault endpoint.

Affected Products

• KEDA versions prior to 2.17.3
• KEDA versions prior to 2.18.3
• Kubernetes clusters using KEDA TriggerAuthentication with HashiCorp Vault

Discovery Timeline

• 2025-12-22 - CVE-2025-68476 published to NVD
• 2026-04-15 - Last updated in NVD database

Technical Details for CVE-2025-68476

Vulnerability Analysis

The vulnerability is classified as a path traversal flaw [CWE-22] affecting KEDA's HashiCorp Vault integration. KEDA reads the Service Account Token from a path supplied through the TriggerAuthentication custom resource. The handler in pkg/scaling/resolver/hashicorpvault_handler.go called os.ReadFile directly on the user-supplied path without validating that the file is a legitimate Kubernetes projected service account token. This allowed any file readable by the KEDA pod's process to be loaded and forwarded to the configured Vault server.

Root Cause

The root cause is missing validation of the serviceAccount field in the Vault credential specification. The code trusted the caller-supplied file path and forwarded the file contents as authentication material to the Vault endpoint defined in the same resource. There was no check that the loaded file contained a valid JWT or originated from the expected projected service account mount path.

Attack Vector

An attacker who can create or modify a TriggerAuthentication resource in any namespace where KEDA operates sets spec.hashiCorpVault.credential.serviceAccount to an arbitrary file path such as /etc/passwd or a path containing Kubernetes secrets. The attacker also configures the Vault address to a server they control. When KEDA processes the resource, it reads the target file and sends its contents to the attacker's server as part of the Vault authentication request.

// Patch excerpt: pkg/scaling/resolver/k8s_validator.go
package resolver

import (
	"fmt"
	"os"
	"strings"

	"github.com/golang-jwt/jwt/v5"
)

var parser = jwt.NewParser()

func readKubernetesServiceAccountProjectedToken(path string) ([]byte, error) {
	jwt, err := os.ReadFile(path)
	if err != nil {
		return []byte{}, err
	}
	if err = validateK8sSAToken(jwt); err != nil {
		return []byte{}, err
	}
	return jwt, nil
}

func validateK8sSAToken(saToken []byte) error {
	claims := jwt.MapClaims{}
	_, _, err := parser.ParseUnverified(string(saToken), &claims)
	if err != nil {
		return fmt.Errorf("error validating token: %w", err)
	}
	sub, err := claims.GetSubject()

Source: KEDA security patch commit 15c5677. The fix introduces a JWT validation step that parses the file as a service account token and rejects non-token files before they are transmitted.

Detection Methods for CVE-2025-68476

Indicators of Compromise

• TriggerAuthentication resources where spec.hashiCorpVault.credential.serviceAccount references paths outside /var/run/secrets/kubernetes.io/serviceaccount/.
• TriggerAuthentication resources pointing to an external or unexpected Vault address.
• Outbound HTTPS requests from the KEDA operator pod to untrusted hosts that include payloads matching the contents of sensitive files.
• Recent creation or modification of TriggerAuthentication objects by service accounts not normally responsible for autoscaler configuration.

Detection Strategies

• Audit Kubernetes API logs for create and update operations on triggerauthentications.keda.sh resources and inspect the serviceAccount and Vault address fields.
• Inspect cluster manifests for TriggerAuthentication objects referencing absolute paths such as /etc/passwd, /root/, or Kubernetes secret mount paths.
• Compare the running KEDA version against 2.17.3 and 2.18.3 to identify vulnerable deployments.

Monitoring Recommendations

• Enable Kubernetes audit logging for the keda.sh API group and forward events to a centralized log store.
• Monitor egress traffic from the KEDA operator namespace for connections to Vault endpoints not on an approved allowlist.
• Alert on RBAC changes that grant create or patch rights on triggerauthentications to non-administrative principals.

How to Mitigate CVE-2025-68476

Immediate Actions Required

• Upgrade KEDA to version 2.17.3 or 2.18.3 or later in all clusters.
• Review all existing TriggerAuthentication resources and remove or correct any that reference file paths outside the standard projected service account directory.
• Restrict RBAC permissions so only trusted administrators can create or modify TriggerAuthentication objects.
• Rotate any credentials, secrets, or tokens that may have been accessible from the KEDA pod's filesystem.

Patch Information

The vulnerability is fixed in KEDA 2.17.3 and 2.18.3. The patch removes the unrestricted os.ReadFile import from pkg/scaling/resolver/hashicorpvault_handler.go and adds a new validator in pkg/scaling/resolver/k8s_validator.go that parses the loaded file as an unverified JWT and rejects content that does not present valid service account claims. Details are available in the KEDA Security Advisory GHSA-c4p6-qg4m-9jmr.

Workarounds

• Disable use of HashiCorp Vault authentication in TriggerAuthentication resources until the upgrade is applied.
• Apply a Kubernetes admission policy (OPA Gatekeeper, Kyverno) that rejects TriggerAuthentication objects where spec.hashiCorpVault.credential.serviceAccount does not start with /var/run/secrets/kubernetes.io/serviceaccount/.
• Limit the KEDA operator pod's filesystem visibility by mounting only required volumes and avoiding host path mounts.

# Example Kyverno policy snippet enforcing allowed serviceAccount path
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: restrict-keda-vault-sa-path
spec:
  validationFailureAction: Enforce
  rules:
    - name: validate-vault-sa-path
      match:
        any:
          - resources:
              kinds:
                - TriggerAuthentication
      validate:
        message: "hashiCorpVault.credential.serviceAccount must be a projected SA token path"
        pattern:
          spec:
            hashiCorpVault:
              credential:
                serviceAccount: "/var/run/secrets/kubernetes.io/serviceaccount/*"