CVE-2026-115357 in OpenBao
Summary
by MITRE • 10/22/2026
OpenBao before 2.6.4 and 2.7.x before 2.7.1 fails to write response audit entries for the unauthenticated sys/generate-root, sys/rekey, and sys/rekey-recovery-key endpoints when request audit logging succeeds but response audit logging fails. An attacker using these endpoints can complete root token generation or rekey operations without a corresponding response audit record, hindering forensic detection.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified in OpenBao versions prior to 2.6.4 and the 2.7.x series before version 2.7.1 represents a critical failure in the integrity of security auditing mechanisms within the HashiCorp Vault-compatible secret management platform. This flaw specifically affects unauthenticated endpoints responsible for sensitive administrative operations, namely sys/generate-root, sys/rekey, and sys/rekey-recovery-key. These endpoints are fundamental to the lifecycle management of root credentials and encryption keys, which serve as the highest level of privilege within the system. The core technical deficiency lies in the asymmetric handling of audit log entries during these specific workflows. When a request is successfully processed by the server but the subsequent attempt to write the corresponding response audit entry fails due to internal errors or configuration issues, the system does not roll back the operation nor does it flag the event as incomplete for security monitoring purposes. Instead, the action completes successfully from an operational standpoint while leaving no digital footprint in the response logs that would typically capture details such as success status, timestamps, and outcome metadata.
This behavior creates a significant blind spot in forensic detection capabilities, aligning with CWE-778 Insufficient Logging of Events. By allowing critical administrative actions to proceed without generating complete audit trails, the vulnerability undermines the principle of non-repudiation and accountability. Attackers who gain access to these unauthenticated endpoints can execute root token generation or rekey operations effectively bypassing detection mechanisms that rely on response logs for anomaly identification. In a typical security monitoring setup, analysts look for patterns in both request and response data to identify unauthorized privilege escalation or key manipulation attempts. The absence of the response record means that while the initial attempt might be logged as a request, the successful completion of the malicious action remains invisible to standard log aggregation tools and intrusion detection systems configured to monitor audit trails.
The operational impact is severe because these endpoints control access to the master encryption keys and root tokens required for full system compromise. An attacker exploiting this flaw can establish persistent administrative access or alter the encryption scheme without leaving definitive evidence in the response logs, thereby complicating incident response efforts. The inability to correlate request initiation with successful execution hampers the ability of security teams to determine exactly when a breach occurred or what actions were taken during that window. This gap is particularly dangerous because it allows for stealthy persistence mechanisms where an adversary can maintain control over the vault infrastructure while evading standard alerting rules designed to catch unauthorized administrative changes.
To mitigate this risk, organizations running affected versions of OpenBao must upgrade immediately to version 2.6.4 or later in the 2.7.x branch, which addresses the logging logic to ensure that audit entries are either successfully written or the operation is aborted if writing fails. Additionally, administrators should review their current log storage infrastructure for reliability issues such as disk space exhaustion or network connectivity problems with external logging services like Elasticsearch or Splunk, as these environmental factors often contribute to response logging failures. Implementing strict access controls and multi-factor authentication on administrative endpoints can further reduce the attack surface by limiting who can interact with these sensitive APIs. Continuous monitoring of request logs for unauthenticated calls to sys/generate-root and related endpoints should also be enforced, even in the absence of corresponding response data, as any such attempt is inherently suspicious given that these operations are typically restricted to authenticated administrators under normal secure configurations. This approach aligns with MITRE ATT&CK techniques related to Defense Evasion through Log Manipulation and Credential Access via Root Token generation, ensuring that detection strategies account for potential logging bypasses by adversaries seeking to maintain stealth during a compromise.