HashiCorp disclosed a Vault Secrets Operator vulnerability this week. Then, the bug, tracked as CVE-2026-8715, scores a 9.6 on the CVSS scale. It can lead to privilege escalation inside a Kubernetes cluster.
- CVE: CVE-2026-8715
- CVSS: 9.6 (Critical · CVSSv3)
- Product: HashiCorp Tooling
- Affected: 1.3.0
- Impact: Vault Secrets Operator vulnerable to arbitrary file read and credential exfiltration via AppRole secretIDPath
- Status: No confirmed exploitation yet
- Patched in: 1.5.0
- EPSS: 0.3% (30-day)
- Action: Update to 1.5.0 now
Why It Matters
Vault Secrets Operator syncs secrets from HashiCorp Vault into Kubernetes. Also, many teams trust it to keep credentials out of pod manifests. So, a flaw that leaks pod files undercuts that whole model. An attacker does not need cluster-admin rights to try this. Still, namespace-level access alone can open the door to real damage. Because Kubernetes RBAC often grants broad edit rights by default, more tenants than expected could trigger this path.
How the Attack Works
The flaw sits in the AppRole setup. Version 1.3.0 added a secretIDPath field to point at a Secret ID file. But the validation only checked for path traversal and file size. HashiCorp’s advisory says the check “did not restrict which files on the operator pod’s filesystem could be referenced.” Since a tenant also controls the Vault connection address, they can point secretIDPath at any readable file. It then sends that file’s contents to a server the tenant controls. So, that design flaw turns two small tenant-controlled fields into a serious data leak. This Vault Secrets Operator flaw needs specific namespace permissions, not open network access.
Affected Versions
The issue affects Vault Secrets Operator 1.3.0 through 1.4.1. Versions before 1.3.0 lack the secretIDPath field entirely, so they escape this bug. Meanwhile, HashiCorp has not published how many clusters run the affected releases. No source confirms active exploitation, and no public proof-of-concept exists for this flaw today.
Patch and Mitigation Steps
HashiCorp fixed this Vault Secrets Operator vulnerability in version 1.5.0. That release removes the secretIDPath field completely. Teams must migrate to secretRef, which points to a Kubernetes Secret instead of a raw file path. However, deployments that never let tenants edit VaultAuth or VaultConnection resources were never at risk. Still, HashiCorp recommends every team using AppRole review its setup and upgrade soon.
Support Our Threat Intelligence
If you find our CVE report and cybersecurity news helpful, consider supporting our work.