Loading story…
HashiCorp disclosed two security issues in Vault affecting availability and access controls. One advisory, HCSEC-2026-05, warns that Vault's KVv2 engine is vulnerable to a policy bypass involving metadata and secret deletion operations, creating a denial-of-service condition and allowing actions that should have been restricted by policy.
A second advisory, HCSEC-2026-08, says Vault is also vulnerable to denial of service through unauthenticated root token generation and rekey operations. Together, the disclosures indicate that both authenticated policy enforcement paths and unauthenticated operational workflows in Vault can be abused to disrupt service, underscoring the need for organizations running Vault to review affected deployments and apply vendor guidance promptly.
See affected versions and whether adversaries are exploiting it.
4 events from the most recent confirmed update back to the earliest known activity.
HashiCorp published advisory HCSEC-2026-08 describing a Vault denial-of-service vulnerability tied to unauthenticated root token generation and rekey operations.
HashiCorp fixed CVE-2026-3605, a Vault KVv2 access-control flaw that let an authenticated user delete unauthorized secrets and trigger denial of service. The issue was addressed in Vault Community Edition 2.0.0 and Vault Enterprise 2.0.0, 1.21.5, 1.20.10, and 1.19.16.
HashiCorp published advisory HCSEC-2026-05 describing a Vault KVv2 vulnerability involving metadata and secret deletion policy bypass that can lead to denial of service.
HashiCorp published advisory HCSEC-2026-06 for a server-side request forgery vulnerability in Vault affecting ACME challenge validation through attacker-controlled DNS. The issue was included in the April 16, 2026 set of Vault security advisories referenced by the Canadian Centre for Cyber Security.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
4 references tracked. Mallory keeps watching after this page renders.
cyber.gc.ca
Open sourcediscuss.hashicorp.com
Open sourcediscuss.hashicorp.com
Open sourcecvefeed.io
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
HashiCorp disclosed **CVE-2026-8715**, a critical flaw in **Vault Secrets Operator** that allows arbitrary file reads and credential exfiltration through the AppRole `secretIDPath` configuration. The vulnerability affects versions **1.3.0 through 1.4.1** and can be exploited by a tenant with limited Kubernetes RBAC permissions to read files from the operator pod filesystem and send their contents to a tenant-controlled endpoint. The issue could expose sensitive credentials and create a path to privilege escalation inside a Kubernetes cluster. HashiCorp addressed the flaw in **Vault Secrets Operator 1.5.0**, and the **Canadian Centre for Cyber Security** issued advisory **AV26-817**, referencing HashiCorp bulletin **HCSEC-2026-28** and urging administrators to review the advisory and apply the available update.
Aug 15, 2026
A high-severity flaw tracked as **CVE-2026-54725** affected `bank-vaults/vault-secrets-webhook` before version `1.23.1`, allowing attacker-controlled `vault-addr` Kubernetes annotations to trigger outbound HTTP requests during admission and send a ServiceAccount JWT to an attacker-controlled endpoint. The issue created a server-side request forgery condition and, in some configurations, could enable cluster-wide service account token theft through the Kubernetes `TokenRequest` API when the `vault-serviceaccount` setting was used. The project fixed the issue in **`v1.23.1`** by no longer trusting object-supplied Vault addresses by default and validating them against an operator-controlled allowlist before any network connection or token minting occurs. The patch also blocks unsafe targets such as metadata endpoints, restricts private-address use unless explicitly allowed, rejects userinfo-bearing addresses, and prevents the `vault-skip-verify` annotation from disabling TLS verification unless operators explicitly enable that behavior; deployments that relied on per-object Vault address overrides may now be denied at admission time.
Aug 1, 2026
Two high-severity vulnerabilities in OpenClaw exposed paths for authenticated users to gain access beyond their intended roles. **CVE-2026-32042** affects versions before `2026.2.25` and allows an attacker with valid shared gateway authentication to present a self-signed, unpaired device identity and bypass pairing requirements, then self-assign elevated operator scopes including `operator.admin`. The issue is classified as `CWE-863` and effectively turns a trusted but unapproved device identity into a route for privilege escalation. A second flaw, **CVE-2026-32051**, affects OpenClaw versions before `2026.3.1` and allows users with `operator.write` scope to reach owner-only tool surfaces such as gateway and cron through agent runs in scoped-token deployments. The authorization mismatch lets lower-privileged authenticated users perform control-plane actions that should be restricted to owners, creating high risk to confidentiality, integrity, and availability. Advisories for both issues point to fixes and security guidance through GitHub and VulnCheck.
Jun 29, 2026