Summary
A server-side request forgery (SSRF) flaw in vault-secrets-webhook allows attacker-controlled Vault endpoints to receive Kubernetes ServiceAccount JWTs via crafted Pod annotations.
When a cluster uses the mutating webhook to inject secrets into Pods, a malicious or compromised workload can redirect vault client requests and exfiltrate credentials, enabling broader cluster abuse.
Affected context
This vulnerability affects Kubernetes clusters that deploy the vault-secrets-webhook to inject secrets into Pods using Vault-related annotations.
It is most relevant where:
- Pod creators can freely set or modify annotations such as
vault.security.banzaicloud.io/vault-addrandvault.security.banzaicloud.io/vault-serviceaccount - The webhook trusts these annotations as configuration for outbound Vault connections
- ServiceAccount tokens are available in Pod contexts and used for Vault authentication
Under these conditions, annotation-controlled endpoints may cause sensitive tokens to be sent outside of intended trust boundaries.
Exploit preconditions
- Attack surface: Kubernetes API / Pod creation path using the mutating webhook
- Required access: Ability to create or modify Pods (or related resources) with custom Vault annotations in the affected namespace or cluster
- Trigger point: Admission-time mutation when vault-secrets-webhook processes
vault-addrandvault-serviceaccountannotations and establishes a Vault client - Why exploitation is possible: The webhook accepts attacker-supplied Vault addresses and uses ServiceAccount JWTs for authentication without adequately constraining or validating the target endpoint, enabling SSRF and credential exfiltration
Why this happens
The core issue is a trust boundary violation where configuration data from untrusted Pod annotations is used directly to construct outbound network requests.
parseVaultConfig() treats vault.security.banzaicloud.io/vault-addr and related annotations as authoritative configuration, and MutateConfigMap/MutateSecret then invoke newVaultClient to connect to that address.
This behavior aligns with CWE-918: Server-Side Request Forgery (SSRF), where a server-side component makes arbitrary outbound requests based on user-controlled input, leaking authentication material and expanding the effective attack surface.
Potential impact
- Exfiltration of Kubernetes ServiceAccount JWTs to attacker-controlled Vault instances
- Unauthorized access to Vault-managed secrets using stolen credentials
- Lateral movement within the cluster by impersonating workloads or accessing additional services
- Escalation of privileges if high-privilege ServiceAccounts are targeted
- Broader compromise of application data and configuration relying on Vault-based secrets
General mitigation guidance
Effective mitigation focuses on constraining where and how external endpoints are derived and reducing the trust placed in workload-controlled metadata.
Pattern-based defenses include:
- Enforcing a fixed, centrally managed Vault address in webhook configuration rather than accepting it from Pod annotations
- Restricting which annotations are honored, and treating all workload-supplied endpoints as untrusted
- Validating outbound targets against an allowlist of internal, expected Vault hosts before establishing connections
- Minimizing ServiceAccount token privileges used for Vault authentication and segmenting roles by namespace or workload
- Applying admission controls or policies (e.g., OPA/Gatekeeper, Kyverno) to block risky annotations from untrusted tenants
These patterns aim to keep sensitive tokens and secret flows within known trust boundaries and reduce the blast radius of any misconfiguration.
How teams detect issues like this
Detection typically relies on both configuration review and runtime monitoring:
- Static analysis or policy checks on webhook code to flag use of user-controlled annotations for network endpoints
- Kubernetes admission policies that detect and deny Pods with suspicious or non-standard Vault annotations
- Centralized logging of webhook activity, especially outbound Vault connections and target addresses, to spot anomalous destinations
- Network monitoring and egress controls that alert on or block traffic from the webhook to unexpected Vault hosts or external networks
- Periodic review of ServiceAccount usage patterns and Vault authentication logs to identify unusual token consumers or access attempts
