The vulnerability resides in the vault-secrets-webhook component, which parses the vault.security.banzaicloud.io/vault-addr annotation. Prior to version 1.23.1, the annotation value is used as the address of a Vault instance when creating a Vault client. An attacker who can add or modify this annotation on any Kubernetes resource subject to the webhook—such as ConfigMaps or Secrets—can cause the webhook to establish an outbound HTTP request to an attacker‑controlled address. The code path then triggers a TokenRequest API call that leaks the requesting ServiceAccount JWT to the malicious Vault endpoint. This allows the attacker to retrieve the token for any ServiceAccount whose pods have been mutated by the webhook, potentially enabling credential theft, secret injection, and lateral movement within the cluster. The weakness is a Server‑Side Request Forgery (CWE‑918).

The product affected is vault-secrets-webhook from the bank‑vaults project. All releases prior to version 1.23.1 contain the flaw. The attack could be exploited against any Kubernetes cluster where this webhook is deployed, regardless of cloud provider or on‑premises installation.

The CVSS score of 9.6 classifies the vulnerability as critical. The EPSS score of < 1% indicates a low probability of exploitation at present, and the vulnerability is not yet listed in the CISA KEV catalog. Nevertheless, the attack vector is through the admission webhook mechanism; a user with permission to create or modify resources that are inspected by the webhook (for example, a developer with pod creation rights) can trigger the SSRF. Once triggered, the attacker obtains a valid ServiceAccount JWT that can be used to call the Cluster‑Roles API or further pods, leading to widespread credential compromise.