CVE-2026-54725 Overview
CVE-2026-54725 is a Server-Side Request Forgery [CWE-918] vulnerability in vault-secrets-webhook, a Kubernetes mutating webhook maintained by the bank-vaults project that injects secrets directly into Pods. Versions prior to 1.23.1 accept a per-object vault.security.banzaicloud.io/vault-addr annotation without validation. When combined with the vault.security.banzaicloud.io/vault-serviceaccount annotation, an attacker who can create or modify Kubernetes objects can redirect the webhook to an attacker-controlled Vault endpoint. The webhook then transmits the ServiceAccount JSON Web Token (JWT) to that endpoint, exposing cluster identity credentials.
Critical Impact
Attacker-controlled annotations coerce the webhook into leaking ServiceAccount JWTs to arbitrary external endpoints, enabling identity theft and lateral movement across the Kubernetes cluster.
Affected Products
- bank-vaults/vault-secrets-webhook versions prior to 1.23.1
- Kubernetes clusters running the webhook as a secret injection mechanism
- Workloads relying on vault.security.banzaicloud.io/* annotations for Vault integration
Discovery Timeline
- 2026-07-31 - CVE-2026-54725 published to the National Vulnerability Database (NVD)
- 2026-07-31 - Last updated in NVD database
Technical Details for CVE-2026-54725
Vulnerability Analysis
The webhook's parseVaultConfig() function in pkg/webhook/config.go reads the vault.security.banzaicloud.io/vault-addr annotation directly from the mutated object and uses it as the destination Vault address. The MutateConfigMap and MutateSecret handlers subsequently invoke newVaultClient in pkg/webhook/webhook.go using that untrusted value.
When the vault.security.banzaicloud.io/vault-serviceaccount annotation is also set, the webhook authenticates to the specified Vault endpoint by presenting the ServiceAccount JWT associated with the workload. Because the endpoint is attacker-supplied, the JWT is delivered to an arbitrary host. This constitutes a Server-Side Request Forgery, with the additional consequence of credential exfiltration.
Root Cause
The root cause is missing validation of object-supplied configuration. Any user with permission to create or edit Pods, ConfigMaps, or Secrets in a namespace covered by the webhook can dictate where the webhook connects. Trust boundaries were not enforced between operator-supplied defaults and object-level annotations.
Attack Vector
An authenticated Kubernetes user with namespace-level object creation rights annotates a workload with a hostile vault-addr value and requests JWT-based authentication. The mutating webhook, running with cluster privileges, contacts the attacker's endpoint and submits the ServiceAccount JWT. The scope is Changed because the vulnerable component operates in the cluster control plane while impact extends to workload identities.
// VaultConfig represents vault options
type VaultConfig struct {
Addr string
+ AddrFromObject bool
AuthMethod string
Role string
Path string
Source: GitHub commit 76db459
The patch introduces an AddrFromObject flag so the webhook can distinguish operator-configured addresses from object-supplied ones, validate them, and gate insecure options such as skip-verify.
Detection Methods for CVE-2026-54725
Indicators of Compromise
- Outbound HTTPS traffic from the vault-secrets-webhook Pod to hosts other than the operator-configured Vault cluster
- Kubernetes audit log entries showing objects annotated with vault.security.banzaicloud.io/vault-addr referencing untrusted domains or IP literals
- Objects that simultaneously carry vault-addr and vault-serviceaccount annotations authored by non-administrative principals
Detection Strategies
- Query the Kubernetes API server for Pods, Secrets, and ConfigMaps with vault.security.banzaicloud.io/vault-addr annotations and compare values against the allowlisted Vault endpoint
- Alert on DNS resolutions from the webhook workload that target domains outside the sanctioned Vault namespace
- Correlate webhook egress destinations against the operator-provided VAULT_ADDR configured at deployment time
Monitoring Recommendations
- Enable Kubernetes audit logging at the Metadata level for create and update verbs on Pods, ConfigMaps, and Secrets across all namespaces
- Baseline the webhook Pod's outbound network destinations and alert on new egress hosts
- Track ServiceAccount token issuance and authentication events at Vault to identify unexpected client sources
How to Mitigate CVE-2026-54725
Immediate Actions Required
- Upgrade vault-secrets-webhook to version 1.23.1 or later across all clusters
- Rotate ServiceAccount tokens that may have been transmitted while the vulnerable version was deployed
- Audit RBAC to restrict who can annotate Pods, ConfigMaps, and Secrets in namespaces served by the webhook
Patch Information
The fix is available in vault-secrets-webhook v1.23.1. Technical details are documented in the GHSA-r2v3-8gwf-7ghm security advisory and the remediation commit 76db459. The patch validates object-supplied Vault addresses and gates the skip-verify flag behind operator control.
Workarounds
- Apply a NetworkPolicy or egress firewall rule limiting the webhook Pod to the sanctioned Vault endpoint only
- Use an admission controller such as Kyverno or OPA Gatekeeper to reject objects that set vault.security.banzaicloud.io/vault-addr from untrusted principals
- Remove the webhook from namespaces where tenant users can create workloads until the upgrade is complete
# Kyverno policy fragment to block object-supplied vault-addr annotations
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: block-vault-addr-annotation
spec:
validationFailureAction: Enforce
rules:
- name: deny-vault-addr
match:
any:
- resources:
kinds: [Pod, ConfigMap, Secret]
validate:
message: "Setting vault-addr via annotation is not permitted."
pattern:
metadata:
=(annotations):
X(vault.security.banzaicloud.io/vault-addr): "null"
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
