CVE-2026-54725: 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

Should you act?

Critical, preconditions apply

Severe if exploited, but exploitation needs conditions that may not apply to you. This signal is computed from CISA KEV, EPSS and CVSS data; it is not an editorial verdict.

• Not in CISA KEV, but CISA’s SSVC assessment records a public proof-of-concept, so attack code exists.
• EPSS 0.4%, percentile 38: FIRST’s model estimates a 0.4% chance of exploitation activity in the next 30 days, higher than 38% of all scored CVEs (low). EPSS is a probability, not a verdict.
• Needs an account (low (any account)). Exposure depends on who can log in.
• Only applies if your dependency tree includes github.com/bank-vaults/vault-secrets-webhook (Go) <= 1.22.2, fixed in 1.23.1. Check your lockfile, including transitive dependencies.

What it is

vault-secrets-webhook is a Kubernetes mutating webhook that makes direct secret injection into Pods possible. Prior to 1.23.1, parseVaultConfig() in pkg/webhook/config.go accepts the vault.security.banzaicloud.io/vault-addr annotation, MutateConfigMap and MutateSecret call newVaultClient in pkg/webhook/webhook.go, and vault.security.banzaicloud.io/vault-serviceaccount can cause a ServiceAccount JWT to be sent to an attacker-controlled Vault address. This issue is fixed in version 1.23.1.

From the GitHub advisory

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:

No URL scheme validation, no hostname allowlist, no RFC-1918 or link-local filter.

Weakness type: CWE-918.

Product: github.com/bank-vaults/vault-secrets-webhook (Go) · Assigned by: GitHub_M · Published: 2026-07-31

Affected and fixed versions

Severity scores

• Attack vector: network (remotely reachable)
• Attack complexity: low
• Privileges required: low (any account)
• User interaction: none
• Scope: changed (can affect other components)

CVSS measures how bad a flaw is if exploited, not how likely exploitation is. Read it next to the exploitation data below.

Exploitation and urgency

• CISA KEV: not listed (no confirmed in-the-wild exploitation known to CISA).
• CISA SSVC assessment: exploitation poc, automatable no, technical impact partial.
• FIRST EPSS (model of 2026-10-21): 0.45% probability of exploitation activity in the next 30 days; percentile 38.

Timeline

• 2026-07-31 — CVE record last updated
• 2026-07-31 — CVE record published by GitHub_M
• 2026-07-31 — GitHub-reviewed advisory GHSA-r2v3-8gwf-7ghm published (critical)

Sources and references

Original sources first. Version and fix details should always be confirmed against the vendor or project advisory.

Vulnerability records

1. GitHub Advisory GHSA-r2v3-8gwf-7ghm github.com
2. CVE.org record CVE-2026-54725 cve.org
3. NVD entry CVE-2026-54725 nvd.nist.gov

Other references from the CVE record and advisory

1. github.com github.com
2. github.com github.com
3. github.com github.com

Critical Go advisories · Today’s Security Digest