GPU VulnDB

Database/Control plane, storage & DevOps

Vault Secrets Operator: tenant-controlled AppRole config reads operator pod files and exfiltrates them

CVE-2026-8715Control plane, storage & DevOpscurated

Impact

A tenant with only limited Kubernetes RBAC can point the operator's AppRole authentication configuration at an arbitrary path inside the operator pod and at an endpoint they control, causing the operator to read local files and transmit their contents outward. The Vault Secrets Operator pod holds the credentials that mint secrets for the whole cluster, so what leaks is not one namespace's data but the material used to fetch every namespace's. On a shared GPU cluster that is a direct path from a single tenant namespace to cluster-wide privilege escalation. Confidentiality and integrity are rated high with changed scope; availability is unaffected.

Who can reach it

A Kubernetes user or service account with limited RBAC in the cluster - enough to create or modify the operator's AppRole auth custom resource. Authentication to the cluster is required, but no cluster-admin rights.

What to do

Upgrade Vault Secrets Operator to 1.5.0 (affected: 1.3.0 through 1.4.1) and roll the operator deployment - a single pod restart, no node drain and no GPU workload impact. Because the flaw exfiltrates credentials rather than just reading them, rotate the Vault AppRole secret IDs and any tokens the operator pod held before deciding you are clear.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-8715https://discuss.hashicorp.com/t/hcsec-2026-28-vault-secrets-operator-vulnerable-to-arbitrary-file-read-via-approle-secretidpath/77645http://www.openwall.com/lists/oss-security/2026/08/28/3

Related entries

All Control plane, storage & DevOps entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.