CVE-2025-68476: 
CBL Mariner vulnerability analysis and mitigation

CVE-2025-68476 is an Arbitrary File Read vulnerability in KEDA (Kubernetes-based Event Driven Autoscaling) affecting resources that use TriggerAuthentication to configure HashiCorp Vault authentication. The vulnerability was disclosed on December 22, 2025, and affects KEDA Operator versions ≤2.17.2 and ≤2.18.2, as well as Metrics Server versions <2.9.0. It carries a CVSS v3.1 base score of 7.7 (High) and a CVSS v4.0 base score of 8.2 (High) (GitHub Advisory, Microsoft MSRC).

The root cause is insufficient path validation (CWE-22: Path Traversal; CWE-863: Incorrect Authorization) in the hashicorpvault_handler.go file within KEDA's scaling resolver. Specifically, the spec.hashiCorpVault.credential.serviceAccount field in a TriggerAuthentication resource was passed directly to os.ReadFile() without validating that the path pointed to a legitimate Kubernetes service account token. An attacker with permissions to create or modify a TriggerAuthentication resource could supply an arbitrary filesystem path (e.g., /etc/passwd, /etc/shadow, or any secret file accessible to the KEDA pod) as the serviceAccount value, causing KEDA to read and transmit the file's contents to an attacker-controlled Vault server as part of the authentication request. The fix introduced a new readKubernetesServiceAccountProjectedToken() function that validates the file content is a valid Kubernetes JWT service account token (with a system:serviceaccount: subject prefix) before use (GitHub Advisory, Patch Commit).

Successful exploitation allows an authenticated attacker to exfiltrate the contents of any file readable by the KEDA operator pod on the Kubernetes node's filesystem. Sensitive data at risk includes Kubernetes secrets, service account tokens, TLS private keys, cloud provider credentials, and system files such as /etc/passwd. Because the KEDA operator typically runs with elevated privileges in a cluster, the scope of readable files can be broad, potentially enabling lateral movement or privilege escalation within the Kubernetes environment (GitHub Advisory).

1. Reconnaissance: Identify a target Kubernetes cluster running a vulnerable KEDA version (Operator ≤2.17.2 or ≤2.18.2). Confirm KEDA is deployed using kubectl get deploy keda-operator -n keda -o jsonpath="{.spec.template.spec.containers[0].image}".
2. Obtain permissions: Acquire Kubernetes credentials with create or update permissions on TriggerAuthentication resources in any namespace (e.g., via a compromised developer account or misconfigured RBAC).
3. Set up attacker-controlled Vault server: Deploy or control a server that mimics a HashiCorp Vault endpoint and logs all incoming authentication requests, including the JWT/token body.
4. Craft malicious TriggerAuthentication: Create a TriggerAuthentication manifest specifying spec.hashiCorpVault.credential.serviceAccount with the target file path (e.g., /etc/shadow, /var/run/secrets/kubernetes.io/serviceaccount/token, or any sensitive file on the node) and point spec.hashiCorpVault.address to the attacker-controlled server.
5. Apply the resource: Submit the malicious TriggerAuthentication to the cluster using kubectl apply -f malicious-triggerauth.yaml.
6. Capture exfiltrated content: When KEDA processes the resource, it reads the specified file and sends its contents to the attacker's Vault server as the JWT credential in the authentication request. Capture and decode the file content from the server logs (GitHub Advisory, Patch Commit).

• Kubernetes Audit Logs: create or update events on TriggerAuthentication resources by unexpected or low-privileged users, especially with spec.hashiCorpVault.credential.serviceAccount set to paths outside /var/run/secrets/kubernetes.io/serviceaccount/.
• Network: Outbound HTTPS connections from the KEDA operator pod to unknown or external Vault-like endpoints (non-standard Vault addresses); unusual authentication requests to HashiCorp Vault servers not in the approved inventory.
• KEDA Operator Logs: Error messages referencing file read failures for unexpected paths, or successful Vault authentication attempts using tokens from non-standard paths.
• File System: Evidence of TriggerAuthentication resources in the cluster with serviceAccount fields pointing to arbitrary filesystem paths (e.g., /etc/passwd, /etc/shadow, /proc/, or other sensitive locations) — auditable via kubectl get triggerauthentication -A -o yaml | grep serviceAccount.

Upgrade KEDA Operator to version 2.17.3 or 2.18.3 (or any version ≥2.19.0), and Metrics Server to version ≥2.9.0, which contain the fix that validates service account token paths before reading (GitHub Advisory). For Microsoft Azure deployments, patched packages are available as cbl2_keda_2.4.0-30 and azl3_keda_2.14.1-7 (Microsoft MSRC). As a workaround if immediate upgrade is not possible, strictly restrict Kubernetes RBAC so that only trusted administrators have create or update permissions on TriggerAuthentication resources. Additionally, audit all existing TriggerAuthentication configurations for suspicious serviceAccount path values.

Red Hat acknowledged the vulnerability and published a security advisory tracking it (Red Hat CVE). The vulnerability was also picked up by GitLab's advisory database and INCIBE-CERT. Community discussion has been limited, with no major media coverage or notable researcher commentary beyond standard CVE tracking and aggregation sites.