Critical SSRF in vault-secrets-webhook Lets Attackers Steal Kubernetes ServiceAccount Tokens via Vault Annotations (CVE-2026-54725)

A newly published GitHub Security Advisory (GHSA-r2v3-8gwf-7ghm) discloses a critical vulnerability (CVE-2026-54725, CVSS 9.6) in vault-secrets-webhook, the Kubernetes mutating admission webhook used by the bank-vaults project to inject HashiCorp Vault secrets into pods. According to the advisory, the webhook reads the vault.security.banzaicloud.io/vault-addr annotation from any ConfigMap or Secret submitted for admission and uses that value, unvalidated, as the Vault server address. When the object also contains a vault:-prefixed value, the webhook process synchronously connects to that attacker-supplied address during admission review — with no scheme, hostname, or RFC-1918/link-local filtering, and TLS verification optionally disabled via a companion vault-skip-verify annotation.

The advisory further states that the webhook's ClusterRole grants serviceaccounts/token:create cluster-wide, and that a paired vault-serviceaccount annotation lets the same attacker-controlled ConfigMap or Secret specify which ServiceAccount's JWT the webhook should mint and forward, as a login POST, to the attacker's address.

Why It Matters

The reported impact is significant because the trigger requires only the ability to create or update a ConfigMap or Secret in a namespace watched by the webhook — a low bar in many multi-tenant clusters. Per the advisory, this gives an attacker two things from a single admission-time request: (1) the ability to make the privileged webhook pod issue arbitrary outbound HTTP requests, including to cloud instance metadata services (the PoC targets 169.254.169.254), and (2) exfiltration of a valid ServiceAccount JWT that can be replayed against the real Vault server to read whatever secrets that SA's Vault role is authorized to access. This affects any environment running bank-vaults/vault-secrets-webhook with default RBAC as described in the advisory.

What Defenders Should Do Now

• Identify whether vault-secrets-webhook is deployed in your clusters and check the version against the advisory's fix guidance once available.
• Audit who can create or update ConfigMaps/Secrets in namespaces the webhook watches — treat that as a privileged capability until patched.
• Hunt for the annotations named in the advisory (vault-addr, vault-skip-verify, vault-serviceaccount) on recently created ConfigMaps/Secrets, especially values pointing to non-Vault or internal/metadata IPs.
• Review webhook pod egress logs for outbound connections to unexpected or internal-only addresses (including 169.254.169.254) at admission time.
• Consider network-policy egress restrictions on the webhook pod and, where feasible, restrict the webhook's serviceaccounts/token:create RBAC grant to only the namespaces/SAs it legitimately needs.
• Rotate ServiceAccount tokens and review Vault audit logs for logins from unexpected source addresses if compromise is suspected.

This is developing, net-new intelligence based solely on the GitHub Security Advisory published today; a patched version and further remediation detail may follow. See the original advisory for full technical detail: GHSA-r2v3-8gwf-7ghm.