freenode
Security & Cryptography

Vault Secrets Operator leaks privileged token to tenants

CVE-2026-8715 in versions 1.3.0–1.4.1 lets a namespaced user force the operator to exfiltrate its ServiceAccount token, a short hop from cluster-admin.

HashiCorp has fixed a flaw in Vault Secrets Operator that allowed ordinary tenants to steal the operator's ServiceAccount token, a credential with rights to read and write Secrets in every namespace and to mint service account tokens cluster-wide.

CVE-2026-8715 affects versions 1.3.0 through 1.4.1 and is corrected in 1.5.0. HashiCorp tracked it as HCSEC-2026-28. The issue was reported by Artem Cherezov, with independent co-reporting by Trung Nguyen of CyStack.

Version 1.3.0 added a field on the namespaced VaultAuth resources so the operator could load an AppRole secret ID from a file inside its own pod. That path was not limited to safe locations, and the companion VaultConnection address could be set to any URL. Both custom resource types are meant for tenant editors under the roles the operator's Helm chart publishes.

A tenant who can create those objects in one namespace and expose an HTTP endpoint the operator can reach can point the path at the operator's projected ServiceAccount token and the address at their own listener. The operator then reads the token and POSTs it to the attacker in an AppRole login body. No cluster-scoped permission is required on the attacker's side.

The leaked token's create right on serviceaccounts/token across the cluster is one hop from full cluster-admin. Installations that never grant tenants create or modify access on VaultAuth or VaultConnection are not exposed.