| Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
|---|---|---|---|
| github.com/kedacore/keda/v2 | go | >= 2.18.0, < 2.18.3 | 2.18.3 |
| github.com/kedacore/keda/v2 | go | < 2.17.3 | 2.17.3 |
The security vulnerability is an arbitrary file read in KEDA's HashiCorp Vault authentication mechanism. The root cause is insufficient validation of the file path provided for the Kubernetes Service Account token. The vulnerable function is github.com/kedacore/keda/v2/pkg/scaling/resolver.HashicorpVaultHandler.token.
Analysis of the patch commit 15c5677f65f809b9b6b59a52f4cf793db0a510fd reveals that the token function in pkg/scaling/resolver/hashicorpvault_handler.go was modified. Previously, the function used os.ReadFile to read the file specified in vh.vault.Credential.ServiceAccount, which is derived from the TriggerAuthentication resource. An attacker could set this to a path like /etc/passwd, and KEDA would read and send the content of this file to the Vault server during authentication.
The patch replaces the direct os.ReadFile call with a new function, readKubernetesServiceAccountProjectedToken. This new function, defined in the newly added pkg/scaling/resolver/k8s_validator.go file, reads the file but then calls validateK8sSAToken to verify its contents. The validation function checks if the file is a valid JWT and, crucially, if the 'sub' (subject) claim within the JWT starts with "system:serviceaccount:". This ensures that only legitimate Kubernetes Service Account tokens are processed, preventing the reading of arbitrary files.
github.com/kedacore/keda/v2/pkg/scaling/resolver.HashicorpVaultHandler.tokenpkg/scaling/resolver/hashicorpvault_handler.go
A Semantic Attack on Google Gemini - Read the Latest Research