HashiCorp Vault CVE-2026-5807: Brief Summary of Unauthenticated Denial of Service Blocking Root Token and Rekey Operations

Introduction

An unauthenticated attacker with nothing more than network access to a HashiCorp Vault API can completely block administrators from running root token generation and rekey ceremonies, two of the most critical operational workflows in any Vault deployment. CVE-2026-5807, disclosed on April 16, 2026, with a CVSS 3.1 score of 7.5, exposes a design flaw in how Vault handles concurrency for these administrative operations. It is also the third time HashiCorp has patched denial-of-service issues in these same endpoint families.

Technical Information

Root Cause: Unauthenticated Endpoints and a Single Operation Slot

The vulnerability comes from two design decisions in HashiCorp Vault that interact badly. First, three families of administrative endpoints were completely unauthenticated:

• sys/rekey
• sys/generate-root
• sys/replication/dr/secondary/generate-operation-token

These endpoints were left unauthenticated because the ceremony itself requires presenting seal or recovery key fragments, which served as the trust mechanism. But an attacker needs no token, key fragment, or other authentication to initiate or cancel an operation on these endpoints. Network access to the Vault API is enough.

Second, Vault's concurrency model for root token generation and rekey workflows permits only a single in-progress operation slot at any given time. The constraint is deliberate. These are sensitive cryptographic ceremonies, and allowing concurrent operations would add significant complexity and risk.

The vulnerability, classified under CWE-770 (Allocation of Resources Without Limits or Throttling), exists because nothing prevents an unauthenticated caller from monopolizing that single slot.

Attack Flow

The exploitation path is straightforward:

1. The attacker identifies a network-reachable Vault instance. The target endpoints are standard Vault API paths, so discovery is trivial for anyone with access to the API.

2. The attacker sends an HTTP request to one of the vulnerable endpoints (for example, sys/generate-root/attempt) to initiate a new root token generation operation. This occupies the single in-progress operation slot.

3. Before any legitimate administrator can interact with the operation, the attacker sends a cancellation request (for example, a DELETE to sys/generate-root/attempt), freeing the slot momentarily.

4. The attacker immediately re-initiates the operation and occupies the slot again. By automating this loop of initiate and cancel requests, the attacker keeps persistent control of the operation slot.

5. Legitimate administrators who try to start their own root token generation or rekey ceremony find the slot perpetually occupied or in a transitional state. They are effectively locked out of these critical workflows.

The CVSS 3.1 vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. The attack works over the network, has low complexity, needs no privileges or user interaction, and completely denies availability of the targeted administrative functions.

Impact on Governance and Incident Response

The timing makes this worse than an ordinary service disruption. Root token generation and rekey ceremonies typically happen during incident response, key rotation after a suspected compromise, or disaster recovery. An attacker who can block these workflows at will can stop an organization from recovering its own infrastructure when recovery matters most.

Patch Information

HashiCorp fixed CVE-2026-5807 in Vault Community Edition 2.0.0 and Vault Enterprise 2.0.0, published on April 14, 2026 (tagged v2.0.0). No 1.x version line has a backported fix. Other vulnerabilities disclosed on the same day received backports, but CVE-2026-5807 is fixed only in the 2.0.0 release.

What the Patch Changes

Unlike the earlier incremental fixes, this one is architectural. In Vault 2.0.0, all three vulnerable endpoint families require a valid Vault token in addition to the seal or recovery key fragments. An attacker who can reach the Vault API but holds no valid token can no longer initiate, cancel, or interfere with these administrative workflows.

The Vault 2.0.0 release notes document these changes:

• sys/generate-root and sys/replication/dr/secondary/generate-operation-token endpoints are now authenticated by default. The previous unauthenticated behavior can be restored by adding "generate-root" or "generate-operation-token" to a new HCL configuration key called enable_unauthenticated_access.
• sys/rekey endpoints are now authenticated by default. The old behavior can be restored the same way, by including "rekey" in the enable_unauthenticated_access configuration.

Before the patch, the quorum of unseal or recovery key shares was the only trust mechanism for these endpoints. Now callers must present both a valid Vault token and the appropriate key fragment. The documentation explicitly states that this requirement is meant to stop an attacker from sending key update requests with bogus key fragments that block legitimate operations.

Backward Compatibility Escape Hatch

For operators who cannot upgrade immediately, or who have automation that calls these endpoints without a token, the enable_unauthenticated_access configuration parameter provides backward compatibility. Enabling it explicitly re-opens the vulnerable behavior, so it should be treated as a temporary measure only.

Upgrade Considerations

Upgrading to a new major version requires careful planning. HashiCorp recommends:

1. Set up a test instance in a fully isolated network environment to prevent unwanted cluster communication or credential revocation.
2. Back up the Vault data store using the snapshot CLI command or API endpoints, because the upgrade process may alter the data store.
3. Review the release notes and important changes documentation for version 2.0.0, because new functionality may require configuration adjustments.
4. Apply the upgrade in the isolated test environment and confirm that critical workflows, authentication methods, and secrets engines work correctly.
5. Proceed with the production upgrade once testing succeeds.

Affected Systems and Versions

Any Vault deployment running a version in the affected column is vulnerable. The fix exists only in the 2.0.0 release line, and no 1.x version has a backport for this CVE.

Vendor Security History

HashiCorp has patched denial-of-service vulnerabilities in these unauthenticated endpoint families twice before, and the issues keep recurring in the same code path:

The earlier fixes (rate limiting, per-operation patches) targeted specific abuse patterns and kept the unauthenticated design in place. The 2.0.0 patch requires authentication outright, which concedes that the unauthenticated design itself was the root problem. The sequence shows how hard it is to balance secure, unauthenticated key recovery ceremonies against availability protections.

The XlabAI Team of Tencent Xuanwu Lab and the Atuin Automated Vulnerability Discovery Engine discovered and responsibly disclosed the vulnerability. As of the disclosure date, there was no evidence of active exploitation in the wild.

References

• NVD: CVE-2026-5807
• CVE Record: CVE-2026-5807
• HCSEC-2026-08: Vault Vulnerable to Denial of Service via Unauthenticated Root Token Generation/Rekey Operations
• Vault v2.0.0 Release on GitHub
• Vault Important Changes: Previously Unauthenticated Endpoints Require Authentication
• Vault Upgrade Documentation
• HCSEC-2025-11: Vault Vulnerable to Recovery Key Cancellation Denial of Service
• HCSEC-2025-32: Incomplete Fix for Previous Vault DoS Issue
• HashiCorp Officially Joins the IBM Family
• IBM Completes Acquisition of HashiCorp