CVE-2025-52894: Openbao Denial of Service Vulnerability

CVE-2025-52894 Overview

CVE-2025-52894 affects OpenBao, an open-source secrets management platform used to store and distribute sensitive data such as credentials, certificates, and cryptographic keys. Versions before v2.3.0 expose unauthenticated rekey and recovery-rekey endpoints that allow remote attackers to cancel in-progress rekey operations. The endpoints also lacked audit logging, leaving the abuse invisible to defenders. An attacker can repeatedly disrupt root key and recovery key rotation, producing a denial of service against critical key management workflows. The flaw is tracked as an improper input validation issue [CWE-20] and corresponds to upstream HashiCorp Vault advisory HCSEC-2025-11 / CVE-2025-4656.

Critical Impact
Unauthenticated network attackers can cancel root rekey and recovery rekey operations on vulnerable OpenBao instances, preventing key rotation and leaving no audit trail of the abuse.

Affected Products

OpenBao versions prior to v2.3.0
OpenBao v2.2.0 and later without disable_unauthed_rekey_endpoints=true configured
Deployments exposing sys/rekey/* and sys/rekey-recovery-key/* HTTP endpoints to untrusted networks

Discovery Timeline

2025-06-25 - CVE-2025-52894 published to NVD
2025-08-12 - Last updated in NVD database

Technical Details for CVE-2025-52894

Vulnerability Analysis

OpenBao's HTTP handler registered the rekey routes /v1/sys/rekey/init, /v1/sys/rekey/update, /v1/sys/rekey/verify, and the corresponding sys/rekey-recovery-key/* endpoints without authentication and without audit instrumentation. These endpoints exist so operators can initialize, advance, or cancel a rekey ceremony when unseal keys are split among multiple holders. Because cancellation does not require any token, any unauthenticated client able to reach the listener can issue a DELETE request that aborts an in-progress rekey. Repeating this action prevents legitimate operators from ever completing a rotation, disrupting incident response, key compromise recovery, and routine rotation policy enforcement.

Root Cause

The rekey endpoints were intentionally reachable without authentication so that quorum holders without OpenBao tokens could participate in unseal-key ceremonies. The design did not anticipate hostile cancellation traffic and omitted both audit logging and an authenticated alternative. As a result, the endpoints violated the principle of least privilege and provided an unauthenticated control plane over key rotation lifecycle state.

Attack Vector

Exploitation requires only network reachability to an OpenBao listener. An attacker sends unauthenticated HTTP requests that cancel any active rekey or recovery-rekey operation. No user interaction, privileges, or prior knowledge of cluster state is needed. Because the endpoints were not audited prior to the fix, the cancellation leaves no log entry, complicating incident detection.

text

// Source: https://github.com/openbao/openbao/commit/fe75468822a22a88318c6079425357a02ae5b77b
// Patch in changelog/1496.txt

release-note:security
core/sys: Add listener parameter (`disable_unauthed_rekey_endpoints`,
default: `false`) to optionally disable unauthenticated rekey operations
(to `sys/rekey/*` and `sys/rekey-recovery-key/*`) for a listener. This
will be set to true in a future release; see the deprecation notice for
more information. Auditing is now enabled for these endpoints as well.
CVE-2025-52894. Upstream HCSEC-2025-11 / CVE-2025-4656.

The handler-level fix conditionally registers the rekey routes and wraps them with handleAuditNonLogical so that requests are now logged:

// Source: https://github.com/openbao/openbao/commit/fe75468822a22a88318c6079425357a02ae5b77b
// http/handler.go

// Register without unauthenticated rekey, if necessary.
if props.ListenerConfig == nil || !props.ListenerConfig.DisableUnauthedRekeyEndpoints {
    mux.Handle("/v1/sys/rekey/init", handleRequestForwarding(core,
        handleAuditNonLogical(core, handleSysRekeyInit(core, false))))
    mux.Handle("/v1/sys/rekey/update", handleRequestForwarding(core,
        handleAuditNonLogical(core, handleSysRekeyUpdate(core, false))))
    mux.Handle("/v1/sys/rekey/verify", handleRequestForwarding(core,
        handleAuditNonLogical(core, handleSysRekeyVerify(core, false))))
    mux.Handle("/v1/sys/rekey-recovery-key/init", handleRequestForwarding(core,
        handleAuditNonLogical(core, handleSysRekeyInit(core, true))))
    mux.Handle("/v1/sys/rekey-recovery-key/update", handleRequestForwarding(core,
        handleAuditNonLogical(core, handleSysRekeyUpdate(core, true))))
    mux.Handle("/v1/sys/rekey-recovery-key/verify", handleRequestForwarding(core,
        handleAuditNonLogical(core, handleSysRekeyVerify(core, true))))
}

Detection Methods for CVE-2025-52894

Indicators of Compromise

Unexpected HTTP requests against /v1/sys/rekey/* or /v1/sys/rekey-recovery-key/* from unauthorized source IP ranges.
Repeated DELETE requests to rekey endpoints coinciding with operator reports of failed key rotation ceremonies.
Absence of audit log entries for rekey activity on pre-patch versions, since auditing was not enabled for these endpoints.

Detection Strategies

Monitor reverse proxy and load balancer access logs for unauthenticated calls to sys/rekey paths and alert on requests from outside management subnets.
After upgrading to v2.3.0 or later, enable file or syslog audit devices and watch for rekey cancellations not initiated by a known operator workflow.
Correlate rekey ceremony failure events from operations tooling with network telemetry showing concurrent external access to the affected endpoints.

Monitoring Recommendations

Ingest OpenBao audit logs and proxy logs into a centralized analytics platform and build alerts for any sys/rekey* request volume anomalies.
Track rekey operation lifecycle metrics and alert when an init is followed by an unexpected cancellation.
Review listener configuration drift to confirm disable_unauthed_rekey_endpoints remains enabled across all nodes.

How to Mitigate CVE-2025-52894

Immediate Actions Required

Upgrade OpenBao to v2.3.0 or later, which incorporates commit fe75468822a22a88318c6079425357a02ae5b77b.
For deployments running v2.2.0 through pre-v2.3.0, set disable_unauthed_rekey_endpoints=true on every listener exposed to untrusted networks.
Restrict network reachability of OpenBao listeners to trusted management ranges using firewall, security group, or service mesh policies.

Patch Information

The fix is available in OpenBao v2.3.0 and was committed as fe75468822a22a88318c6079425357a02ae5b77b. The patch adds the disable_unauthed_rekey_endpoints listener option, wraps the rekey handlers with handleAuditNonLogical so requests are audited, and signals a future release in which unauthenticated rekey endpoints will be disabled by default. See the OpenBao Security Advisory GHSA-prpj-rchp-9j5h and the OpenBao Rekey Deprecation Guide for upgrade and migration guidance.

Workarounds

Place an authenticating reverse proxy or load balancer in front of OpenBao and deny requests to sys/rekey/* and sys/rekey-recovery-key/* from unauthorized IP ranges.
Bind OpenBao listeners to internal management interfaces only and require VPN or bastion access for operator key ceremonies.
Schedule rekey ceremonies during controlled maintenance windows and monitor for concurrent unauthorized requests against the affected endpoints.

bash

# Listener configuration example for OpenBao v2.2.0+
listener "tcp" {
  address                          = "0.0.0.0:8200"
  tls_disable                      = false
  tls_cert_file                    = "/etc/openbao/tls/tls.crt"
  tls_key_file                     = "/etc/openbao/tls/tls.key"
  disable_unauthed_rekey_endpoints = true
}