CVE-2025-68476
📋 TL;DR
An arbitrary file read vulnerability in KEDA allows attackers with permissions to create or modify TriggerAuthentication resources to read any file from the node's filesystem where the KEDA pod resides. The vulnerability affects KEDA deployments using HashiCorp Vault authentication via TriggerAuthentication. Attackers can exfiltrate sensitive system files like secrets, keys, or configuration files by directing file content to a server they control.
💻 Affected Systems
- KEDA (Kubernetes-based Event Driven Autoscaling)
⚠️ Manual Verification Required
This CVE does not have specific version information in our database, so automatic vulnerability detection cannot determine if your system is affected.
Why? The CVE database entry doesn't specify which versions are vulnerable (no version ranges provided by the vendor/NVD).
🔒 Custom verification scripts are available for registered users. Sign up free to download automated test scripts.
- Review the CVE details at NVD
- Check vendor security advisories for your specific version
- Test if the vulnerability is exploitable in your environment
- Consider updating to the latest version as a precaution
⚠️ Risk & Real-World Impact
Worst Case
Complete compromise of node filesystem including exfiltration of all secrets, service account tokens, SSH keys, and sensitive configuration files, potentially leading to cluster-wide compromise.
Likely Case
Exfiltration of specific sensitive files like /etc/passwd, service account tokens, or application secrets stored on the node.
If Mitigated
Limited impact due to restricted RBAC permissions preventing unauthorized TriggerAuthentication creation/modification.
🎯 Exploit Status
Exploitation requires RBAC permissions to create/modify TriggerAuthentication resources. The vulnerability is straightforward to exploit once permissions are obtained.
🛠️ Fix & Mitigation
✅ Official Fix
Patch Version: 2.17.3 or 2.18.3
Vendor Advisory: https://github.com/kedacore/keda/security/advisories/GHSA-c4p6-qg4m-9jmr
Restart Required: Yes
Instructions:
1. Update KEDA to version 2.17.3 or 2.18.3 using your preferred deployment method (helm, kubectl, etc.). 2. Restart all KEDA pods to ensure the new version is active. 3. Verify the update was successful by checking pod versions.
🔧 Temporary Workarounds
Restrict TriggerAuthentication RBAC
allLimit permissions to create or modify TriggerAuthentication resources to only trusted users/service accounts.
kubectl create role restricted-triggerauth --verb=get,list --resource=triggerauthentications.keda.sh
kubectl create rolebinding restrict-triggerauth --role=restricted-triggerauth --user=untrusted-user
Disable HashiCorp Vault Authentication
allTemporarily disable or remove TriggerAuthentication configurations using HashiCorp Vault authentication.
kubectl delete triggerauthentication <name> --namespace <namespace>
🧯 If You Can't Patch
- Implement strict RBAC controls to prevent unauthorized users from creating or modifying TriggerAuthentication resources
- Monitor and audit all TriggerAuthentication creation/modification events and HashiCorp Vault authentication attempts
🔍 How to Verify
Check if Vulnerable:
Check KEDA version: kubectl get pods -n keda -l app=keda-operator -o jsonpath='{.items[*].spec.containers[*].image}'. If version is below 2.17.3 or 2.18.3 and uses HashiCorp Vault authentication, you are vulnerable.Check Version:
kubectl get pods -n keda -l app=keda-operator -o jsonpath='{.items[*].spec.containers[*].image}' | grep -o 'v[0-9]\+\.[0-9]\+\.[0-9]\+'Verify Fix Applied:
Confirm KEDA version is 2.17.3 or higher (for 2.17.x) or 2.18.3 or higher (for 2.18.x) using: kubectl get pods -n keda -l app=keda-operator -o jsonpath='{.items[*].spec.containers[*].image}'📡 Detection & Monitoring
Log Indicators:
- Unusual TriggerAuthentication creation/modification events
- Failed or unusual HashiCorp Vault authentication attempts with unexpected file paths
- KEDA operator logs showing file read errors or unexpected path validation
Network Indicators:
- Outbound connections from KEDA pods to unexpected external servers during Vault authentication
SIEM Query:
source="kubernetes" ("TriggerAuthentication" AND ("create" OR "update" OR "modify")) OR ("hashiCorpVault" AND "authentication" AND "failed")