KEDA CVE-2025-68476

Exploitation requires Kubernetes RBAC permission to create or modify a TriggerAuthentication resource in the cluster, and the target KEDA resource must use TriggerAuthentication configured for HashiCorp Vault authentication (spec.hashiCorpVault.credential.serviceAccount). The attacker also needs to direct the Vault authentication request to a server they control to receive the exfiltrated file contents. The primary limiting factor is the PR:H prerequisite: only users with create/update rights on TriggerAuthentication can exploit it - the advisory's sole effective workaround is strictly restricting those RBAC permissions to trusted users. Affected versions are KEDA <2.17.3 and 2.18.0-2.18.3 (fixed in 2.17.3, 2.18.3, and >=2.19.0).

This is a genuine but access-gated confidentiality issue rather than a critical broadly-exploitable flaw. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/SC:H, score 8.2) is internally consistent with the description: exploitation requires PR:H - specifically Kubernetes RBAC permission to create or modify a TriggerAuthentication custom resource - and the SC:H (subsequent system High) correctly reflects that the read escapes the KEDA pod to reach the underlying node's filesystem. This is not a PR:N remote-unauth bug; the 'AV:N' reflects that TriggerAuthentication objects are submitted via the Kubernetes API, but the privilege prerequisite is the real gate. Supporting signals are muted: EPSS is 0.55% (44th percentile), there is no CISA KEV listing (no public exploit identified at time of analysis), and no public POC. The signals are consistent - moderate CVSS, low EPSS, no active exploitation - indicating a real-but-targeted risk requiring an existing foothold with meaningful cluster RBAC, not a mass-exploitation candidate. The source-code diff independently confirms the root cause (an unvalidated os.ReadFile on the user-supplied ServiceAccount path, replaced by a JWT-validating reader), raising confidence that the fix and description are accurate.

An attacker who has already obtained Kubernetes RBAC rights to create or modify TriggerAuthentication resources (e.g., a low-trust tenant, compromised CI service account, or malicious insider) crafts a TriggerAuthentication pointing spec.hashiCorpVault.credential.serviceAccount at an arbitrary node path such as /etc/passwd or a mounted secret, and sets the Vault address to a server they control. When KEDA authenticates, it reads that file and sends its contents to the attacker's server, exfiltrating node secrets and system files. No public POC or exploit code is currently identified.