KEDA CVE-2025-68476 Patch Stops Arbitrary File Reads

A critical KEDA vulnerability — tracked as CVE-2025-68476 — allows an attacker with the ability to create or modify TriggerAuthentication resources to read arbitrary files from the node filesystem by abusing the HashiCorp Vault service account credential handling in vulnerable KEDA releases, and maintainers have issued patches in KEDA v2.17.3 and v2.18.3 to close the gap.

Background​

KEDA (Kubernetes Event-driven Autoscaler) is widely used to scale workloads in Kubernetes clusters based on external event sources. One of its configuration primitives, TriggerAuthentication, enables KEDA to authenticate to external systems such as HashiCorp Vault. In the vulnerable code path, a TriggerAuthentication may specify where to obtain a service account token that KEDA will use when performing Vault authentication. Prior to the patch, KEDA did not sufficiently validate the path used to load that token, enabling a malicious or compromised user with permission to create or update TriggerAuthentication objects to point KEDA at arbitrary files on the node and have their contents read and used during Vault authentication requests. The issue was scored as High (CVSS v4.0 base score 8.2) because exploitation can result in high confidentiality impact — arbitrary file contents could include system secrets, SSH keys, configuration files and other sensitive material. The vulnerability is tracked publicly as CVE-2025-68476 and recorded across major vulnerability databases.

---

Why this vulnerability matters (overview)​

• Attack surface: A TriggerAuthentication resource is a CRD used by KEDA to configure how scalers authenticate to external services. In many clusters, TriggerAuthentication creation and modification is permitted to application engineers or CI/CD systems. That makes the resource a realistic target for privilege abuse when CRUD permissions are too broad.
• Impact: Arbitrary file read allows exfiltration of secrets, private keys, tokens, and configuration. On nodes hosting KEDA pods, files such as /etc/passwd, systemd unit files, mounted secrets, or container filesystem artifacts could be exposed.
• Exploit complexity: The exploit requires the ability to create or change TriggerAuthentication resources (a cluster or namespace privilege depending on RBAC). It does not require interaction from an operator or admin beyond these API actions, and the vulnerable KEDA process performs the file read and sends the token content as part of Vault authentication flows. The privilege requirement is therefore categorized as high in scoring because the attacker must already be able to modify TriggerAuthentication, but when that permission is incorrectly granted to code or persons it becomes a practical attack vector.

---

Technical root cause​

At a code level, the problem was an insufficient path validation when KEDA loads a service account token file specified by TriggerAuthentication (spec.hashiCorpVault.credential.serviceAccount). The pre-patch code would read the file path provided by the TriggerAuthentication object without validating that the read target was a legitimate projected service-account token file, which allowed attackers to point the parameter to arbitrary files on the node.
The maintainer patch introduces defensive checks in the Vault handler:

• Defaulting the service account path to the canonical projected token file path used by Kubernetes.
• Replacing blind calls to read arbitrary filesystem paths with a new helper that:
• Reads the requested file.
• Performs token validation by parsing the JWT and ensuring it carries a service-account subject (for example, subject beginning with "system:serviceaccount:").
• Only returns the file content if the token passes validation.

This approach reduces the attack surface by refusing to operate on file contents that are not shaped like real service-account tokens.

---

Confirmed affected versions and patches​

• Affected operator versions: KEDA operator releases prior to v2.17.3 (and selected 2.18.x that are older than v2.18.3) are reported affected. The vendor released fixes in v2.17.3 and v2.18.3; code in the main branch also contains the remediation.
• Note: ancillary KEDA components (metrics server vs operator) can have different versioning or backporting patterns. The vendor advisory and multiple vulnerability databases list the operator fix as the canonical remediation; cluster operators should consult their distribution’s KEDA packaging to ensure that the operator image has been updated to the patched tag.

---

Exploitation scenario — step-by-step​

• Attacker obtains permission to create or modify TriggerAuthentication resources in the target namespace (for example by exploiting overly permissive RBAC, a misconfigured CI pipeline, or an account compromise).
• Attacker creates a TriggerAuthentication that sets spec.hashiCorpVault.credential.serviceAccount to a node-local path (for example: /etc/ssh/ssh_host_rsa_key or /var/lib/kubelet/config.yaml).
• When KEDA processes that TriggerAuthentication and performs Vault authentication, it loads the token by reading the file path specified.
• Because the file contents are used in the Vault authentication request, the attacker arranges for the Vault-auth flow to target their controlled endpoint or otherwise encode the file contents to an external system (this can be done by controlling the vault server address or metadata used in the request, depending on scaler configuration).
• Sensitive file contents are exfiltrated from the node where the KEDA pod runs.

Privileges required and defense-in-depth: exploitation depends on the ability to create/modify TriggerAuthentication or to influence an entity that can. For clusters where that CRD is tightly controlled, the risk is much lower; where developers or automation have broad CRD write rights, the risk is higher.

---

Detection: how to tell if you are vulnerable or have been targeted​

• Check KEDA operator version (quick):
  kubectl get deploy keda-operator -n keda -o jsonpath="{.spec.template.spec.containers[0].image}"
  If the version tag is older than v2.17.3 (or older than v2.18.3 for 2.18.x users), plan to update immediately.
• Audit existing TriggerAuthentication objects for unusual serviceAccount file paths:
  kubectl get triggerauthentication --all-namespaces -o yaml | grep -i "serviceAccount" -n
  or use jq to extract values and look for paths that do not match the expected projected token location (/var/run/secrets/kubernetes.io/serviceaccount/token).
• Search cluster audit logs for recent creations/updates of TriggerAuthentication objects by unexpected principals (service accounts, human users, CI bots). Look for sudden or unauthorized changes around the time sensitive files might have been accessed.
• On nodes running KEDA pods, review outbound network connections from KEDA pods (e.g., kube-proxy/netstat, eBPF observers, or Cilium/Hubble logs) for connections created as part of Vault authentication coming from the KEDA operator to unusual destinations; this could indicate exfil attempts.
• Check Vault server logs for unusual authentication attempts or tokens presented from unexpected paths or clients. Rotate any Vault credentials if suspicious activity is detected.
• Threat-hunting: look for evidence of exfiltrated file contents appearing in places they should not — for example, new secrets registering in remote artifact stores or unexpected TLS certificates presented outside expected change windows.

No public proof-of-concept exploit code was found in major public repositories or searchable exploit feeds at the time of reporting; however, the attack technique is straightforward given the necessary permissions, so defenders should assume an exploit is feasible in practice until patched.

---

Immediate mitigation and remediation steps​

• Patch KEDA operator(s): Upgrade to v2.17.3, v2.18.3, or any later patched release. Ensure your operator images come from trusted registries and match vendor-supplied tags. A timely upgrade eliminates the direct vulnerability in KEDA itself.
• Harden RBAC: Constrain who (and which service accounts) can create or modify TriggerAuthentication resources. Apply least-privilege policies:
• Remove broad CREATE/UPDATE rights on TriggerAuthentication CRDs unless explicitly needed.
• Use RoleBindings and ClusterRoleBindings to restrict write access to a small set of trusted identities.
• Audit & alert: Put an audit rule in place to notify when TriggerAuthentication objects are created or modified. Investigate all recent changes, especially those originating outside change windows or by unfamiliar principals.
• Inspect and rotate secrets: If suspicious TriggerAuthentication objects are found or if misconfigurations existed prior to patching, consider rotating:
• Vault tokens and roles that may have been used during the attack window.
• Any system credentials (SSH keys, API keys, service account tokens) that could have been read from exposed files.
• Network controls: Enforce egress controls for KEDA operator pods so they cannot reach attacker-controlled external endpoints. Limit network egress from control-plane and operator pods where feasible.
• Config hardening: Require that serviceAccount token paths in TriggerAuthentication are validated or removed; avoid custom paths unless strictly necessary and validated. The vendor fix enforces token-like shape, but cluster controls should avoid allowing arbitrary file paths to be supplied at all.

---

Longer-term defensive recommendations (architectural)​

• Shift to least-privilege automation: Many cluster compromise paths come from overly permissive CI/CD or developer automation. Review the design of automation that needs to write CRDs and move such responsibilities to dedicated, audited service accounts with narrow scopes.
• Adopt admission controls: Use validating admission controllers (e.g., OPA Gatekeeper, Kyverno) to block TriggerAuthentication objects that contain disallowed file paths or non-standard configuration. This provides an additional, centralized point to enforce policies beyond RBAC.
• Isolate critical operator workloads: Run operator workloads (including autoscalers and controllers) in dedicated namespaces with strict network policies and PSP/PSP-like controls (Pod Security Admission) to reduce lateral movement if a controller is misused.
• Continuous scanning for misconfigurations: Implement scans that identify unusual CRD usage patterns, unexpected file path references, or drift from approved templates. Integrate checks into CI pipelines to prevent risky manifests from being applied.
• Threat modeling for CRDs: Treat custom resources and operator APIs as attack surfaces; include them in threat models, red-team test plans, and security reviews.

---

Risk analysis and context-specific advice​

• For clusters where only cluster operators (trusted humans) can write TriggerAuthentication, this vulnerability represents a low immediate risk but still warrants patching because human credentials can be phished or compromised.
• For organizations that grant developer or CI system access to write cluster-level or namespace-level CRDs, the risk is high: the vulnerability allows those actors to escalate the value of their permissions to extract node-level secrets. Tightening RBAC and applying admission controls is essential for such platforms.
• Cloud-managed Kubernetes clusters that provide centralized operators or managed KEDA offerings should confirm whether provider-managed KEDA instances are already patched. If KEDA is provided as part of a managed service, consult the provider’s advisories and coordinate remediation strategy.
• The lack of a public proof-of-concept should not be taken as a sign the vulnerability is safe — the attack is conceptually simple given permission to manipulate TriggerAuthentication. Defenders should operate on the assumption that adversaries with cluster write privileges could weaponize the flaw quickly.

---

How to verify your patch worked (validation checklist)​

• Confirm operator image version is updated to a patched tag:
  kubectl get deploy keda-operator -n keda -o jsonpath="{.spec.template.spec.containers[0].image}"
• Inspect the operator logs for errors related to service account token handling; the patched code logs validation failures where non-token content was attempted to be used.
• Attempt a controlled validation: create a TriggerAuthentication referencing a non-token file path in a sandbox cluster. With the patched operator, KEDA should reject or fail token validation rather than read and use the file content.
• Re-run your audit queries and ensure no TriggerAuthentication resources contain arbitrary filesystem paths.
• If possible, run an admission controller policy to block non-conforming serviceAccount paths, and confirm the policy is enforced post-upgrade.

---

Final assessment and takeaways​

CVE-2025-68476 is a clear example of how flexible operator APIs and CRDs can expand attack surfaces when combined with permissive RBAC and insufficient input validation. The underlying bug — trusting a user-supplied file path and using that file content as a token without shape validation — is straightforward, trivial to understand, and straightforward to remediate. The KEDA maintainers implemented a practical fix by defaulting to the canonical service-account projected token path and validating token content before use. Immediate action priorities for cluster operators:

• Patch KEDA operator to the vendor-released fixed versions.
• Tighten RBAC so TriggerAuthentication write access is limited to trusted identities.
• Audit existing TriggerAuthentication objects and rotate any potentially exposed credentials.

Treat this vulnerability as high-risk in environments where developers or automation can write CRDs. Remediation is simple and urgent: update KEDA and harden access controls to reduce the chance that a simple code path will be leveraged to read sensitive files from cluster nodes.

---

Conclusion: CVE-2025-68476 underscores the need for defensive coding and precise RBAC in Kubernetes ecosystems. The fix is available; the real work is in operational hygiene — upgrading, auditing, and restricting who can change operator-facing CRDs. Immediate patching and RBAC tightening are the most effective steps to eliminate the attack vector and restore confidence in KEDA-based scaling across production clusters.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center