CVE-2026-115362 in OpenBao
Summary
by MITRE • 10/23/2026
OpenBao before 2.6.4 and 2.7.x before 2.7.1 does not check Secret ID expiration at use in the AppRole auth method, leaving expired Secret IDs valid until the periodic tidy removes them. An attacker holding an expired, untidied Secret ID can log in and gain access beyond its TTL.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/23/2026
The vulnerability identified as a flaw in OpenBao versions prior to 2.6.4 and 2.7.x before 2.7.1 centers on the AppRole authentication method's failure to enforce expiration constraints during the login process. In standard identity management architectures, particularly those utilizing HashiCorp Vault or its forks like OpenBao, credentials such as Secret IDs are issued with a defined Time To Live (TTL). The expectation is that once this TTL expires, the credential becomes invalid and cannot be used for authentication. However, in these affected versions, the backend logic responsible for validating AppRole login requests does not perform an expiration check on the provided Secret ID at the moment of use. Instead, it relies entirely on a background maintenance process known as periodic tidy to remove expired entries from storage. This architectural gap creates a window where credentials that should be considered revoked or invalid remain functionally active until the next scheduled cleanup cycle executes.
From a technical perspective, this represents a critical logic error in access control enforcement mechanisms. When an attacker obtains a Secret ID through information disclosure, brute force, or other means, they can utilize it to authenticate against the AppRole endpoint regardless of whether the credential has passed its expiration timestamp. The system accepts the login request and issues new tokens based on the role's policies, effectively granting the actor access that persists beyond the intended security boundary defined by the original TTL. This behavior undermines the principle of least privilege and temporal isolation, as expired credentials continue to hold valid authentication power within the environment.
The operational impact of this vulnerability is significant for organizations relying on OpenBao for secrets management and identity orchestration. An adversary who has acquired an expired Secret ID can bypass time-based access controls that are typically designed to limit the blast radius of compromised credentials. This allows for prolonged unauthorized access, potentially leading to data exfiltration, lateral movement within the infrastructure, or modification of critical configurations. Since the periodic tidy process may run on intervals ranging from minutes to hours depending on configuration, the window of opportunity for exploitation can be substantial, allowing attackers ample time to establish persistence and escalate privileges before the system automatically revokes access through cleanup routines.
This flaw aligns with CWE-284 Improper Access Control, specifically regarding the failure to enforce expiration policies during authentication checks. It also relates to CWE-613 Insufficient Session Expiration, as the session tokens derived from the exploited login remain valid beyond their intended lifespan due to the lack of immediate validation against credential expiry status. In terms of MITRE ATT&CK framework mapping, this vulnerability facilitates Initial Access and Persistence techniques where attackers leverage compromised credentials that should have been invalidated by time constraints. The attack vector typically involves obtaining a Secret ID through prior compromise or leakage and then using it in an AppRole login request to gain unauthorized entry into the vault system.
Mitigation strategies must prioritize immediate version upgrades to OpenBao 2.6.4 or later, as well as any patched versions of the 2.7.x branch starting with 2.7.1. These releases correct the validation logic to ensure that Secret ID expiration is checked synchronously during the authentication handshake rather than relying solely on asynchronous cleanup processes. In environments where immediate patching is not feasible due to operational constraints, administrators should consider reducing the TTL of AppRole credentials to minimize the window of exposure if an expired credential were somehow exploited. Additionally, implementing strict monitoring and alerting for login attempts using potentially compromised or aged identifiers can help detect exploitation activities in real-time. Regular audits of authentication logs and enforcement of short-lived token policies further reduce the risk associated with this class of vulnerabilities by limiting the value of any single stolen credential regardless of expiration logic flaws.