Vault Secrets Operator AppRole Arbitrary File Read and Credential Exfiltration
HashiCorp Vault Secrets Operator versions 1.3.0 through 1.4.1 improperly constrain the AppRole authentication setting spec.appRole.secretIDPath. Although validation rejects traversal sequences and performs file-type and size checks, it does not limit reads to an approved location. A tenant able to configure VSO resources can cause the cluster-wide controller to read files accessible to its pod, then set a tenant-controlled VaultConnection address so the controller submits the read contents as an AppRole secret_id during authentication. The issue is fixed in version 1.5.0, which removes secretIDPath in favor of spec.appRole.secretRef.
What it means and what to do now: patch path, interim mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
An attacker can exfiltrate arbitrary files readable by the VSO controller, including its projected Kubernetes ServiceAccount credential. The controller identity has cluster-wide read and write access to Kubernetes Secrets and can create ServiceAccount token resources cluster-wide. Theft of that identity can therefore enable cluster-wide secret access, minting tokens for other ServiceAccounts, impersonation of privileged identities, and practical escalation to cluster-admin.
If you can’t patch tonight, do this now.
Until upgrade is complete, prevent untrusted tenants from creating or modifying VaultAuth, VaultAuthGlobal, and VaultConnection resources; prohibit AppRole configurations using spec.appRole.secretIDPath through admission policy; and review or remove broad VSO custom-resource permissions, including Helm chart editor roles. Restrict VSO controller egress with a NetworkPolicy to approved Vault endpoints. Egress restriction can prevent credential exfiltration but does not eliminate the underlying arbitrary-file-read condition.
Patch, then assume compromise.
Upgrade Vault Secrets Operator to version 1.5.0 or later. Migrate existing VaultAuth configurations that use spec.appRole.secretIDPath to spec.appRole.secretRef backed by a Kubernetes Secret containing the AppRole Secret ID.
No public exploits tracked yet. Mallory keeps watching.
10 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.