Beyond the SSRF, the webhook holds excessive cluster-wide serviceaccounts/token:create permissions. When combined with the vault-serviceaccount annotation, an attacker can coerce the webhook to generate a token for any ServiceAccount and transmit that JWT to an attacker-controlled server. This enables attackers to impersonate authorized ServiceAccounts and access sensitive data from the Vault instance. The attack occurs during the admission review process, making it highly effective for users with standard namespace access rights.

Attack Chain

1. Attacker creates or updates a ConfigMap or Secret in a namespace monitored by the vault-secrets-webhook.
2. Attacker injects the vault.security.banzaicloud.io/vault-addr annotation with an attacker-controlled URL or internal metadata endpoint (e.g., 169.254.169.254).
3. Attacker specifies vault.security.banzaicloud.io/vault-serviceaccount pointing to a target ServiceAccount to be exfiltrated.
4. Webhook admission handler intercepts the request and parses the malicious annotations during the admission review cycle.
5. Webhook uses its cluster-wide RBAC permissions to call CoreV1().ServiceAccounts().CreateToken for the requested ServiceAccount.
6. Webhook initiates a synchronous HTTP request via vault.NewClientFromConfigWithContext to the attacker-defined URL.
7. The sensitive ServiceAccount JWT is transmitted via the Authorization header to the attacker-controlled server.
8. Attacker replays the captured JWT against the Vault instance to access unauthorized secrets.

Impact

Successful exploitation allows for the exfiltration of high-privilege ServiceAccount JWTs, leading to complete credential compromise of Vault-managed secrets. Attackers can leverage the webhook's privileged network position to probe internal network infrastructure and cloud metadata services, potentially escalating access within the cloud environment. This vulnerability affects all environments running the vault-secrets-webhook where users have standard resource creation permissions in monitored namespaces.

Recommendation

• Patch the vault-secrets-webhook to version 1.22.3 or higher to incorporate input validation for the vault-addr annotation and improved security controls.
• Audit current ClusterRole definitions for the vault-secrets-webhook to restrict serviceaccounts/token:create permissions to the minimum necessary scope.
• Use network policies to restrict egress traffic from the webhook pod to only allow communication with known, legitimate Vault server endpoints.
• Monitor Kubernetes audit logs for ConfigMap and Secret operations containing the specified vault-security annotations.