Bulletin ID: HCSEC-2026-28
Affected Products / Versions: Vault Secrets Operator 1.3.0 up to 1.4.1; fixed in Vault Secrets Operator 1.5.0.
Publication Date: August 13, 2026
Summary
Vault Secrets Operator 1.3.0 up to 1.4.1 is vulnerable to an arbitrary file read and credential exfiltration issue in the AppRole authentication configuration that may allow a tenant with limited Kubernetes RBAC permissions to read files from the operator pod’s filesystem and transmit their contents to a tenant-controlled endpoint, potentially leading to privilege escalation within the cluster. This vulnerability (CVE-2026-8715) is fixed in Vault Secrets Operator 1.5.0.
Background
Vault Secrets Operator is a Kubernetes operator that synchronizes secrets from HashiCorp Vault into Kubernetes Secrets. When using the AppRole authentication method, the operator authenticates to Vault on behalf of workloads in tenant namespaces using configuration supplied through the VaultAuth and VaultConnection custom resources. The AppRole configuration allows operators to specify how the AppRole Secret ID is sourced for authentication.
Details
Vault Secrets Operator 1.3.0 introduced a spec.appRole.secretIDPath field on the VaultAuth and VaultAuthGlobal custom resources, intended to allow an operator administrator to reference a Secret ID file mounted into the operator pod. The path validation for this field only checked for path traversal sequences and confirmed the target was a regular file below a size limit; it did not restrict which files on the operator pod’s filesystem could be referenced. Because VaultConnection.spec.address is also supplied through a tenant-controlled custom resource, a tenant with create and get permissions on VaultAuth, VaultConnection, and VaultStaticSecret resources in their namespace could set secretIDPath to any accessible file on the operator pod and direct the operator to transmit the file’s contents to a tenant-controlled endpoint as part of an AppRole authentication request. This issue requires an authenticated Kubernetes user holding those namespaced resource permissions, which correspond to the editor ClusterRoles published by the Vault Secrets Operator Helm chart for end users. Deployments that do not grant tenants the ability to create or modify VaultAuth or VaultConnection resources are not affected. Deployments using AppRole authentication but configured without the secretIDPath field prior to 1.3.0 are not affected.
Remediation
Customers should evaluate the risk associated with this issue and consider upgrading to Vault Secrets Operator 1.5.0. Note that version 1.5.0 removes the spec.appRole.secretIDPath field; existing VaultAuth configurations using this field must be migrated to use spec.appRole.secretRef, which references a Kubernetes Secret containing the AppRole Secret ID.
Acknowledgement
This issue was reported to HashiCorp by Trung Nguyen (@everping) of CyStack and Artem Cherezov (cherez0ff (Artem Cherezov) · GitHub).
We deeply appreciate any effort to coordinate disclosure of security vulnerabilities. For information about security at HashiCorp and the reporting of security vulnerabilities, please see https://hashicorp.com/security.