CVE-2025-4656
BaseFortify
Publication date: 2025-06-25
Last updated on: 2025-08-13
Assigner: HashiCorp Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| hashicorp | vault | From 1.14.8 (inc) to 1.16.22 (exc) |
| hashicorp | vault | From 1.14.8 (inc) to 1.20.0 (exc) |
| hashicorp | vault | From 1.17.0 (inc) to 1.17.17 (exc) |
| hashicorp | vault | From 1.18.0 (inc) to 1.18.11 (exc) |
| hashicorp | vault | From 1.19.0 (inc) to 1.19.6 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-1088 | The code has a synchronous call to a remote resource, but there is no timeout for the call, or the timeout is set to infinite. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2025-4656 is a denial of service vulnerability in HashiCorp Vault's rekey and recovery key operations. These operations allow changing the number of unseal key shares and the threshold to unseal the root key, but they cannot run concurrently and are tracked by a nonce. The vulnerability arises because these endpoints are unauthenticated and rely on challenge/response mechanisms instead of API authentication. This flaw allows a malicious actor to send cancellation requests to forcibly cancel an ongoing rekey or recovery key operation, resetting the shares and threshold to 1 and causing a denial of service until a legitimate operator restarts the operation. [1]
How can this vulnerability impact me? :
This vulnerability can cause a denial of service by preventing Vault clients from accessing the Vault until a legitimate operator restarts the rekey or recovery key operation. This means that critical secrets and keys managed by Vault could become temporarily inaccessible, potentially disrupting applications and services that depend on Vault for secure key management. [1]
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring Vault system logs for a specific warning event indicating that the shares/threshold are forcibly set to 1, which signals that a rekey or recovery key operation was cancelled unexpectedly. There are no specific commands provided to detect this vulnerability directly, but reviewing Vault logs for such warnings is recommended. [1]
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to upgrade Vault to Community Edition 1.20.0 or Enterprise Edition 1.20.0 or later patched versions (1.19.6, 1.18.11, 1.17.17, 1.16.22). Until the upgrade, operators should be cautious with rekey and recovery key operations and be prepared to restart these operations if a denial of service occurs due to cancellation. [1]