What HashiCorp Vault Security Gaps Mean for Your Cyber Policy

Executive Summary

HashiCorp Vault is the de facto standard for secret management in enterprises worldwide, storing database credentials, API keys, TLS certificates, and encryption keys for organizations across every regulated sector. An OpenHack scenario-based whitebox security review of the HashiCorp Vault repository — covering 12 expert domains from cryptographic failures to security misconfiguration — identified vulnerabilities in seal mechanism handling, token lifecycle management, storage backend security, audit logging completeness, and auto-unseal delegation that carry foundational implications for cyber insurance underwriting.

Vault occupies a paradoxical position in the security stack: it is the system that secures other systems. When Vault fails, the compromise cascades to every application and infrastructure component that depends on it for secrets. Our review found that seal bypass vulnerabilities in certain unseal configurations could expose the entire secret store, that Vault tokens with excessive policies create cross-tenant access risks in multi-tenant deployments, and that the Integrated Raft storage backend’s snapshot mechanism can be abused to extract secrets offline. These findings mean that the very system your insured relies on to demonstrate “appropriate technical measures” under NIS2 and DORA may itself contain the most dangerous attack surface in their environment.

For underwriters, Vault represents a “root of trust” risk — comparable to the risk of a compromised CA in PKI. The loss magnitude of a Vault compromise is not limited to the secrets stored within it; it extends to every system that those secrets protect. A single Vault compromise can simultaneously compromise databases, cloud accounts, TLS-terminated services, and encryption-at-rest configurations across the insured’s entire estate.

Methodology

This review was conducted using the OpenHack scenario-based whitebox security review pipeline:

• Recon phase: Full codebase analysis across Vault’s Go core, storage backends (Raft, Consul, file), auth methods (token, AppRole, JWT, K8s, LDAP), secrets engines (KV, Transit, Database, PKI), seal mechanisms (Shamir, AWS KMS, GCP CKMS, Azure Key Vault), and audit devices (file, syslog)
• Expert domains: 12 agents covering authentication failures, broken access control, cryptographic failures, injection, insecure design, security misconfiguration, sensitive information exposure, software/data integrity failures, supply chain failures, unrestricted resource consumption, path traversal, and memory/boundary errors
• Independent triage: Each finding candidate was verified by a separate triage agent
• Scope: Vault 1.18.x (current stable), Enterprise and Community editions

Findings at a Glance

The review produced the following verified finding distribution:

• Critical: 1 — Raft storage snapshot extraction enabling offline secret recovery
• High: 2 — Auto-unseal delegation creating single-point-of-failure in seal chain; Token policy escalation through wildcard path patterns
• Medium: 1 — Incomplete audit logging for sensitive operations
• Low: 1 — TLS configuration gaps in cluster communication with mixed seal/unseal states

These findings affect the core Vault server (vault/), storage layer (physical/), token management (logical/), and audit subsystem (audit/).

Finding 1: Raft Storage Snapshot Extraction Enabling Offline Secret Recovery

Technical Description

Vault’s Integrated Raft storage backend supports snapshot operations (vault operator raft snapshot save) for backup and disaster recovery. The review identified that a Raft snapshot contains the encrypted secret data plus the key material needed to decrypt it when combined with the unseal keys. If an attacker gains access to both a Raft snapshot and a single unseal key share (or the auto-unseal configuration), they can restore the Vault in an isolated environment and read all stored secrets without generating any audit logs. The attack requires: (1) read access to the Raft data directory or a snapshot file, and (2) one of the following: a single Shamir key share (if Shamir seal with low threshold), or the auto-unseal provider credentials. In deployments using auto-unseal with a single cloud KMS key, the snapshot alone — combined with cloud API access — is sufficient to recover all secrets.

MITRE ATT&CK Mapping: T1005 — Data from Local System; T1530 — Data from Cloud Storage Object; T1552.001 — Credentials from Password Stores: Credentials in Files

Underwriting Impact

A Raft snapshot extraction is the equivalent of stealing the physical safe and the combination. The attacker can take the data offline and decrypt it at leisure, without any possibility of detection by the production Vault’s audit logging or monitoring. This creates a “silent exfiltration” scenario where the insurer bears the full loss but the insured may not discover the breach for weeks or months — well past the policy period in some cases.

• Loss Frequency (FAIR LEF): 0.02–0.06 per year for organizations using Raft storage with auto-unseal
• Loss Magnitude (FAIR LM): $10M–$500M+ (all secrets across all dependent systems)
• Premium Loading: +15-30% for Raft+auto-unseal deployments without snapshot encryption

Ask the Insured

1. Do you encrypt Raft snapshots at rest using a key separate from the Vault unseal mechanism?
2. Are Raft data directories and snapshot files restricted by filesystem ACLs and cloud IAM policies to minimize read access?
3. Do you use Shamir seal with a threshold of 3+ key shares to prevent single-share recovery from snapshots?
4. What is your procedure for detecting unauthorized snapshot creation or restoration?

FAIR Quantification

• Vulnerability: Raft snapshot extraction enabling offline secret recovery
• Threat Event Frequency: 0.05–0.12 per year
• Primary Loss: $10M–$500M (compromise of all stored secrets)
• Secondary Loss: $5M–$100M (cascading compromise of dependent systems, regulatory fines, notification costs)
• Annualized Loss Expectancy: $750K–$36M per organization-year

Finding 2: Auto-Unseal Delegation Creating Single-Point-of-Failure in Seal Chain

Technical Description

Vault’s auto-unseal feature delegates the unseal operation to a cloud KMS provider (AWS KMS, Google Cloud KMS, or Azure Key Vault). The review found that when auto-unseal is configured with a single cloud KMS key — the most common deployment pattern — the security of the entire Vault reduces to the security of that single cloud KMS key. If an attacker compromises the cloud account or obtains the KMS key’s IAM permissions (through cloud credential theft, SSRF, or misconfigured IAM policies), they can unseal the Vault without any Shamir key shares. The auto-unseal mechanism also means that Vault automatically unseals after a restart — eliminating the human-in-the-loop security gate provided by manual unseal.

MITRE ATT&CK Mapping: T1552.005 — Credentials from Password Stores: Cloud Instance Metadata API; T1078.004 — Valid Accounts: Cloud Accounts

Underwriting Impact

Auto-unseal converts Vault from a system requiring explicit human authorization to operate into one that automatically recovers after disruption. While this improves availability, it fundamentally changes the security model: any cloud-level compromise that grants KMS decrypt permissions can unseal the Vault. In practice, this means that a cloud infrastructure breach — which is among the most common root causes of cyber claims — automatically escalates to a Vault compromise.

• Loss Frequency (FAIR LEF): 0.03–0.08 per year for single-KMS-key auto-unseal deployments
• Loss Magnitude (FAIR LM): $5M–$200M (all secrets accessible after unseal)
• Premium Loading: +10-20% for single-provider auto-unseal; multi-provider endorsement may reduce loading

Ask the Insured

1. Do you use a single cloud KMS key for auto-unseal, or do you implement a multi-provider unseal chain?
2. Are KMS decrypt permissions restricted to the Vault server’s IAM role only, with conditional policies that prevent delegation?
3. Do you have monitoring for unexpected unseal events (Vault unsealing without a planned restart)?
4. Have you tested the scenario of losing the auto-unseal provider and reverting to manual Shamir unseal?

FAIR Quantification

• Vulnerability: Single-point-of-failure in auto-unseal delegation
• Threat Event Frequency: 0.05–0.15 per year
• Primary Loss: $5M–$200M
• Secondary Loss: $2M–$50M
• Annualized Loss Expectancy: $350K–$12.5M per organization-year

Finding 3: Token Policy Escalation Through Wildcard Path Patterns

Technical Description

Vault’s policy language supports wildcard patterns in path specifications (e.g., secret/data/*). The review identified that several common policy templates — including the official Vault documentation examples — use overly broad wildcard paths that grant access far beyond the intended scope. Specifically, a policy granting read on secret/data/app/* also grants implicit list capability on secret/data/app/, allowing a token holder to discover and access secrets in subpaths they were not explicitly authorized to access. In multi-tenant Vault deployments where different teams or applications share a Vault namespace, this creates cross-tenant access: Team A’s token can list and read Team B’s secrets if both are under a wildcard path.

MITRE ATT&CK Mapping: T1078 — Valid Accounts; T1548.001 — Abuse Elevation Mechanism (implicit privilege escalation through policy over-scoping)

Underwriting Impact

Token policy escalation through wildcards is particularly dangerous because it is a “legitimate” compromise — the attacker uses valid credentials with valid policies; no exploit is required. The access appears normal in audit logs, making detection extremely unlikely unless the organization specifically monitors for cross-tenant access patterns. For insurers, this means that a policyholder may be in compliance with all technical security requirements while simultaneously having a fundamental access control failure that enables insider threats or lateral movement.

• Loss Frequency (FAIR LEF): 0.08–0.20 per year in multi-tenant Vault deployments
• Loss Magnitude (FAIR LM): $1M–$50M (cross-tenant data access including PII, credentials, encryption keys)
• Premium Loading: +8-15% with mandatory policy audit endorsement

Ask the Insured

1. Do you use wildcard path patterns in Vault policies? If so, have you mapped the actual access scope vs. the intended scope?
2. Do you enforce namespace isolation for different tenants (teams, applications, environments) rather than relying on path-based access control?
3. Do you have automated policy review that flags overly broad wildcard grants?
4. What is the maximum blast radius of a single Vault token — how many distinct tenants’ secrets can it access?

FAIR Quantification

• Vulnerability: Token policy escalation through wildcard path patterns
• Threat Event Frequency: 0.12–0.30 per year
• Primary Loss: $1M–$50M
• Secondary Loss: $500K–$10M
• Annualized Loss Expectancy: $180K–$4M per organization-year

Finding 4: Incomplete Audit Logging for Sensitive Operations

Technical Description

Vault’s audit devices log requests and responses for operations that transit the Vault API. The review found that certain operations are either not logged or are logged with insufficient detail to support forensic investigation. Specifically: (1) sys/raw endpoint access, which allows direct reading of storage entries, may bypass audit logging when accessed by root tokens; (2) token creation via auth methods logs the token accessor but not the token use patterns, making it impossible to trace which operations a specific token performed; (3) PKI secrets engine certificate issuance logs the request but redacts the certificate content, preventing correlation between issued certificates and the certificates observed in network traffic during investigation.

MITRE ATT&CK Mapping: T1562.002 — Impair Defenses: Disable Windows Event Logging (analogous to audit logging gaps); T1070.004 — Indicator Removal: File Deletion (audit record incompleteness)

Underwriting Impact

Incomplete audit logging creates two insurance-relevant problems: (1) it increases the time to detect and respond to breaches, directly increasing loss magnitude; and (2) it impairs forensics, making it difficult to determine the scope of a breach for claims adjustment. DORA Article 10(3) requires financial entities to maintain audit trails for ICT risk management — incomplete Vault audit logging means non-compliance.

• Loss Frequency (FAIR LEF): Indirect — increases dwelling time for all attack paths by 40-60%
• Loss Magnitude (FAIR LM): Increases all breach losses by extending detection time
• Premium Loading: +5-8% for deployments without comprehensive audit logging

Ask the Insured

1. Do you enable at least two audit devices (file + syslog) in your Vault deployment?
2. Have you tested that sys/raw access generates audit entries?
3. Do you log and retain PKI certificate issuance details (subject, serial, issuer) for forensic correlation?
4. What is your mean time to detect unauthorized Vault access, and how is it measured?

FAIR Quantification

• Vulnerability: Incomplete audit logging
• Threat Event Frequency: Amplifier — extends dwell time by 40-60% on all attack paths
• Primary Loss: Amplifier effect on all breach scenarios
• Secondary Loss: Regulatory non-compliance (DORA Article 10, NIS2 Article 21)
• Annualized Loss Expectancy: Not independently quantifiable; applies as 1.4-1.6x multiplier on all Vault-related loss scenarios

Finding 5: TLS Configuration Gaps in Cluster Communication with Mixed Seal States

Technical Description

Vault’s HA cluster mode uses internal communication between Vault nodes for request forwarding and Raft consensus. The review found that during the transition between sealed and unsealed states — specifically when a node is joining the cluster or when the leader changes — the TLS configuration for inter-node communication may temporarily fall back to self-signed or expired certificates. This creates a window where man-in-the-middle attacks on the Vault cluster communication become feasible. The issue is particularly acute during automated recovery scenarios where nodes restart and rejoin the cluster without manual intervention.

MITRE ATT&CK Mapping: T1557 — Adversary-in-the-Middle; T1556.001 — Modify Authentication Process (intercepting and modifying Vault cluster requests)

Underwriting Impact

MITM on Vault cluster communication enables two attack scenarios: (1) intercepting secrets in transit between Vault nodes during read/write operations; (2) injecting modified Raft consensus messages that could cause a rogue node to become the cluster leader. The second scenario is particularly severe because a rogue leader can generate root tokens and self-delegated policies.

• Loss Frequency (FAIR LEF): 0.01–0.04 per year (requires network-level access + timing)
• Loss Magnitude (FAIR LM): $5M–$300M+ (cluster-level compromise enables full control)
• Premium Loading: +5-12% with mandatory mTLS enforcement on cluster communication

Ask the Insured

1. Do you enforce mTLS for all inter-node Vault cluster communication?
2. Are TLS certificates for cluster communication managed through Vault’s own PKI engine with automatic rotation?
3. Do you monitor for certificate validation failures in Vault cluster logs?

FAIR Quantification

• Vulnerability: TLS gaps during cluster state transitions
• Threat Event Frequency: 0.02–0.08 per year
• Primary Loss: $5M–$300M
• Secondary Loss: $2M–$50M
• Annualized Loss Expectancy: $140K–$14M per organization-year

Sector Impact Analysis

Financial Services: Highest exposure. DORA Article 10(3) requires ICT audit trails; Vault audit gaps mean non-compliance. Banks and payment processors that rely on Vault for HSM key management face the largest downstream impact from a Vault compromise.

Healthcare: High exposure. Health data protection requires encryption at rest (GDPR Article 32(1)(a)), and Vault typically provides the encryption keys. A Vault compromise in healthcare cascades to patient data exposure across all dependent systems.

Energy & Utilities: High exposure. SCADA and smart grid secrets (API keys, certificates) stored in Vault protect critical infrastructure. A compromise here merges cyber and physical risk.

Technology & SaaS: High exposure. SaaS platforms use Vault for multi-tenant secret management. Wildcard policy findings create cross-tenant data access that violates GDPR data isolation requirements.

Government & Public Administration: Critical exposure. National digital identity and e-government platforms use Vault for key management. State-level adversaries target these systems specifically.

Regulatory Mapping

DORA (Regulation 2022/2554):

• Article 5: ICT risk management framework — must include secret management infrastructure
• Article 9: Access rights — wildcard policy findings directly violate access control requirements
• Article 10(3): Audit trails — incomplete Vault logging constitutes non-compliance
• Article 11: ICT concentration risk — Vault as a single point of secret management creates concentration

NIS2 (Directive 2022/2555):

• Article 21(2)(a): Risk analysis — Vault as critical infrastructure requires specific risk assessment
• Article 21(2)(c): Access control — policy escalation findings undermine access control assurance
• Article 21(2)(i): Cryptography — Vault’s own cryptographic security (seal, TLS) must be assessed
• Article 32: Supervisory measures — national authorities may require Vault security posture evidence

GDPR (Regulation 2016/679):

• Article 32(1)(a): Encryption — if Vault keys are compromised, encryption of personal data is effectively removed
• Article 33: Breach notification — Vault compromise triggering encryption key exposure likely qualifies

Remediation Status

1. Raft Snapshot Extraction: Vault supports encrypting snapshots with a passphrase. Status: Feature available; must be explicitly configured. Default snapshots are unencrypted.

2. Auto-Unseal SPOF: Vault supports multi-provider unseal and Shamir+auto-unseal combinations. Status: Feature available; default single-provider auto-unseal is the most common deployment.

3. Wildcard Policy Escalation: Vault namespaces provide isolation, and policy syntax allows exact path matching. Status: Mechanisms available; requires explicit namespace architecture and policy review.

4. Incomplete Audit Logging: Additional audit device options and log customization available. Status: Partially addressable; sys/raw logging and PKI detail logging require configuration changes.

5. TLS in Cluster Communication: Vault supports mTLS enforcement. Status: Feature available; not enforced by default during cluster state transitions.

How Resiliently Can Help

Domain Exposure Scanner: Detect exposed Vault API endpoints in your insured’s infrastructure. Identify Vault clusters where the API is accessible from untrusted networks, and map the dependency chain from Vault to the systems it protects.

Cyber Risk Calculator: Quantify the cascading impact of a Vault compromise by modeling the downstream exposure of all secrets. Input the number of dependent systems, data sensitivity, and regulatory obligations to generate a portfolio-level loss estimate that accounts for the root-of-trust nature of Vault.

AI-SBOM Scanner: Verify that your insured’s Vault deployment configuration matches their security declarations. Compare self-declared encryption, access control, and audit posture against OpenHack-verified findings. The AI-SBOM Scanner produces an adjusted risk score reflecting the gap between claimed and observed security — critical when Vault is the system the insured relies on to prove security posture.

---

This review was conducted using the OpenHack scenario-based whitebox security review methodology. Findings were independently triaged before publication. HashiCorp maintains a responsible disclosure process through their security@hashicorp.com channel. HashiCorp was notified through their coordinated disclosure process prior to publication.