Skip to main content

HashiCorp Vault EUVDEUVD-2026-94641

| CVE-2026-105818 MEDIUM
Insufficient Verification of Data Authenticity (CWE-345)
2026-10-07 HashiCorp GHSA-fxww-hx7x-vxpc
5.9
CVSS 3.1 · Vendor: HashiCorp
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Reach Vault PKI ACME directory endpoint
  2. Delivery
    Complete ACME order with unvalidated identity claims
  3. Exploit
    Vault issues certificate with unverified identities
  4. Execution
    Present certificate to trusting system
  5. Impact
    Impersonate trusted identity

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A08:2025 - Software or Data Integrity Failures
ASVS 5.0
V15 - Secure Coding and Architecture Data authenticity verification
Exploitation Conditions

Requires a Vault PKI secrets engine with the ACME server enabled and operating under the default directory policy - this specific configuration is the precondition, as the flaw is that ACME challenges under that policy do not validate certain certificate identities. Exploitation is further limited to environments where the issued certificates are actually trusted by relying systems (otherwise the unverified identity claim has no impact). The CVSS AC:H reflects this configuration dependency; no user interaction or prior authentication beyond normal ACME client participation is required (PR:N/UI:N). Impact is confined to certificate identity integrity (impersonation); it does not expose confidentiality or cause denial of service.

Impact

This is a moderate-severity integrity flaw rather than an urgent priority. The CVSS 3.1 vector (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N, 5.9 MEDIUM) indicates a network-reachable, unauthenticated issue with HIGH attack complexity and impact limited to integrity (I:H; C:N/A:N) - consistent with the CWE-345 (Insufficient Verification of Data Authenticity) classification and the description of certificates issued with unverified identity claims. The AC:H rating reflects that exploitation depends on a specific, non-default-safe configuration: a Vault PKI mount running the ACME server under the default directory policy. No EPSS score, CISA KEV entry, POC, or SSVC decision data was provided in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The signals are internally consistent - there is no conflict between the network vector and the description, since ACME is a network protocol - but the practical risk is bounded by the HIGH complexity and the requirement that an operator have deployed Vault as an ACME CA whose issued certificates are trusted by relying systems. Treat this as a configuration-hardening and patch-management item for affected Vault PKI deployments rather than a drop-everything emergency.

Exploit ScenarioDerived

An attacker able to reach a Vault PKI mount's ACME directory requests a certificate through the normal ACME challenge flow but includes identity fields (e.g., identifiers the ACME challenges never actually validate) under the default directory policy. Vault issues a certificate asserting those unverified identities, which the attacker then presents to any system configured to trust certificates from that Vault PKI mount, enabling impersonation. No public exploit code was identified in the provided data, and the HIGH attack complexity reflects the need for a vulnerable ACME directory configuration.

This Month Plan within 30 days. Why: MEDIUM severity (CVSS 4.0-6.9).
Patch available 0.1% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Oct 07, 2026

HashiCorp Vault's PKI secrets engine ACME server, when running under the default directory policy, can issue certificates that contain identity claims the ACME challenges never validated, allowing an unauthenticated ACME client (CVSS vector PR:N/UI:N) to obtain a certificate for an identity it does not control and impersonate that identity toward systems that trust the affected Vault PKI mount. The issue is a configuration-dependent certificate-integrity flaw (CVSS 5.9, AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N) rather than an urgent remote-code or data-exposure bug: it requires a PKI mount with the ACME server enabled under the default directory policy and relying systems that actually trust certificates issued by that mount, otherwise the unverified identity has no effect. HashiCorp addressed it in Vault Community Edition 2.1.2 and Vault Enterprise 2.1.2, 1.21.12, 1.20.17, and 1.19.23; no public exploit code and no confirmed active exploitation were identified at time of analysis, and no EPSS score was supplied in the available data.

RemediationAI

Vendor-released patch: upgrade Vault Community Edition to 2.1.2 and Vault Enterprise to 2.1.2, 1.21.12, 1.20.17, or 1.19.23 as appropriate for your release line, following HashiCorp security advisory HCSEC-2026-40 (https://discuss.hashicorp.com/t/hcsec-2026-40-vault-pki-acme-default-directory-policy-may-issue-certificates-with-unverified-identities/77812); since ACME-issued certificates are long-lived and cached by clients, also consider reissuing or revoking certificates issued by affected PKI mounts before the upgrade. If immediate upgrading is not possible, the most direct compensating control is to stop using the default ACME directory policy on exposed PKI mounts and replace it with a customized policy that explicitly restricts which identities/directory entries may be issued, accepting the added configuration and maintenance burden and the risk of breaking automated enrollment for clients that depended on the default behavior; alternatively, disable the ACME server on affected PKI mounts (Vault will no longer automate certificate issuance for those mounts, so certificate provisioning must fall back to manual or alternative tooling). Restricting network access to the Vault ACME endpoints to trusted clients reduces the pool of potential requesters but does not close the validation gap, and because the flaw is in issuance rather than authentication, monitoring and auditing the PKI mount's issued-certificate log for subjects/SANs outside expected names is a useful detective measure rather than a preventive one. No vendor workaround beyond configuration hardening is documented in the available data, and no public exploit code was identified at time of analysis.

Affected VersionsENISA

Vault 1.14.0 <2.1.2
Vault Enterprise 1.14.0 <2.1.2

Affected Packages

euvd vault fix: 2.1.2
euvd vault_enterprise fix: 2.1.2

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 2 packages in euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

The affected component is the ACME (Automated Certificate Management Environment, RFC 8555) server built into Vault's PKI secrets engine, which automates certificate issuance by having clients complete a challenge (such as http-01 or dns-01) that proves control of a requested identifier before the CA signs the CSR. The vulnerability is tracked as CWE-345 (Insufficient Verification of Data Authenticity): under the default ACME directory policy, the server did not constrain the certificate identities it would sign to those actually validated by the completed challenge, so a client could obtain a certificate bearing additional or substitute identity claims that were never proven. The root cause is an authorization/validation mismatch between the challenge result and the subject/SAN set placed into the issued certificate. The supplied CPE data points to cpe:2.3:a:hashicorp:vault and cpe:2.3:a:hashicorp:vault_enterprise (with wildcarded versions), confirming both Community Edition and Enterprise are in scope, with concrete affected version boundaries taken from the HashiCorp advisory. The CVSS attack complexity is High (AC:H) precisely because success depends on the deployment using the default directory policy and on relying parties trusting the mount; Confidentiality and Availability impacts are None, and the sole impact is to Integrity of certificate identity (impersonation).

Know when Vault gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (HashiCorp) PRIMARY 5.9 MEDIUM
AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
vuln.today AI 5.9 MEDIUM

ACME is network-reachable with no prior auth (AV:N/PR:N); reliance on the non-default-safe default directory policy configuration justifies AC:H; impact is impersonation via forged identity, so I:H with C:N/A:N.

3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
4.0 AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (HashiCorp).

CVSS VectorVendor: HashiCorp

Attack Vector
Network
Attack Complexity
High
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
High
Availability
None

Lifecycle Timeline

2
Patch available
Oct 07, 2026 - 23:02 EUVD
CVE Published
Oct 07, 2026 - 21:21 cve.org
MEDIUM 5.9

DescriptionCVE.org

Vault's PKI secrets engine ACME server did not restrict certificate identities that ACME challenges do not validate when issuing certificates under the default directory policy. This may allow an ACME client to obtain a certificate containing unverified identity claims, potentially enabling impersonation toward systems that trust certificates issued by the affected Vault PKI mount. This vulnerability (CVE-2026-105818) is fixed in Vault Community Edition 2.1.2, and Vault Enterprise 2.1.2, 1.21.12, 1.20.17, and 1.19.23.

Threat Intelligence Overview

EPSS Score
0.1%
Top 100% exploitable
Prevalence
High
HashiCorp Vault is widely deployed enterprise secrets-management software
Data Quality
5 sources
Confidence: Medium

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity MEDIUM
CISA KEV No
Public POC No
EPSS 0.1%
Patch available Yes
Active threat No
Deciding rule
MEDIUM severity (CVSS 4.0-6.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation
None
System Exposure· derived
Open
Automatable
No
Human Impact· derived
Medium
Technical Impact
Partial

Priority Score

30
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +30
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.

More in Vault

View all
CVE-2024-0831 MEDIUM POC
6.5 Feb 01

Vault and Vault Enterprise (“Vault”) may expose sensitive information when enabling an audit device which specifies the

CVE-2024-2048 CRITICAL
9.8 Mar 04

Vault and Vault Enterprise (“Vault”) TLS certificate auth method did not correctly validate client certificates when con

CVE-2020-35192 CRITICAL
9.8 Dec 17

The official vault docker images before 0.11.6 contain a blank password for a root user. Rated critical severity (CVSS 9

CVE-2020-12757 CRITICAL
9.8 Jun 10

HashiCorp Vault and Vault Enterprise 1.4.0 and 1.4.1, when configured with the GCP Secrets Engine, may incorrectly gener

CVE-2022-40186 CRITICAL
9.1 Sep 22

An issue was discovered in HashiCorp Vault and Vault Enterprise before 1.11.3. Rated critical severity (CVSS 9.1), this

CVE-2022-36129 CRITICAL
9.1 Jul 26

HashiCorp Vault Enterprise 1.7.0 through 1.9.7, 1.10.4, and 1.11.0 clusters using Integrated Storage expose an unauthent

CVE-2020-10661 CRITICAL
9.1 Mar 23

HashiCorp Vault and Vault Enterprise versions 0.11.0 through 1.3.3 may, under certain circumstances, have existing neste

CVE-2026-4525 HIGH
8.8 Apr 17

Token leakage in HashiCorp Vault and Vault Enterprise (0.11.2 up to 2.0.0, 1.21.5, 1.20.10, and 1.19.16) occurs when an

CVE-2024-7594 HIGH
8.8 Sep 26

Vault’s SSH secrets engine did not require the valid_principals list to contain a value by default. Rated high severity

CVE-2020-16251 HIGH
8.2 Aug 26

HashiCorp Vault and Vault Enterprise versions 0.8.3 and newer, when configured with the GCP GCE auth method, may be vuln

CVE-2020-16250 HIGH
8.2 Aug 26

HashiCorp Vault and Vault Enterprise versions 0.7.1 and newer, when configured with the AWS IAM auth method, may be vuln

CVE-2026-3605 HIGH
8.1 Apr 17

HashiCorp Vault's KVv2 secrets engine allows authenticated users with glob-based policy access to delete secrets outside

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy