CVE-2026-115356 in OpenBao
Summary
by MITRE • 10/23/2026
OpenBao before 2.6.4 and 2.7.x before 2.7.1 does not verify, when renewing a token issued by the Kubernetes Auth method, that the service account token originally used to authenticate is still valid. An authenticated attacker can keep renewing such tokens to persist access after the Kubernetes service account has been deleted.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/23/2026
The vulnerability identified in OpenBao versions prior to 2.6.4 and version 2.7.x prior to 2.7.1 represents a critical authentication logic flaw within the Kubernetes Authentication method. This security issue stems from an insufficient verification process during token renewal operations. Specifically, when a client presents a valid JWT for renewing an existing OpenBao token that was originally issued based on a Kubernetes service account identity, the system fails to re-validate whether the underlying Kubernetes service account remains active and authorized in the cluster. The authentication mechanism trusts the initial validity of the service account at the time of first login but does not perform a subsequent check against the Kubernetes API server during each renewal request. This design oversight creates a significant gap between the identity established at session initiation and the current state of that identity within the orchestration platform, allowing for unauthorized persistence of access even after the source identity has been revoked or removed by cluster administrators.
From an operational perspective, this flaw allows authenticated attackers to maintain persistent access to OpenBao resources long after a legitimate service account has been deleted from the Kubernetes environment. In typical cloud-native deployments, security best practices often involve rotating credentials and deleting compromised or unused service accounts as part of incident response procedures. However, due to this vulnerability, such remediation steps are rendered ineffective because the attacker can continue to renew their OpenBao tokens indefinitely using the old JWT signature, which remains cryptographically valid even if the associated Kubernetes identity no longer exists. This persistence mechanism enables attackers to exfiltrate sensitive data stored in Vault secrets, manipulate infrastructure configurations, or pivot further into the network without triggering alerts related to new authentication attempts, as the system perceives the activity as a continuation of an already authorized session rather than a new login event.
This vulnerability aligns with CWE-287, which describes Improper Authentication, specifically regarding the failure to verify identity during subsequent interactions or renewals. It also maps directly to MITRE ATT&CK technique T1098.004, known as SSH Authorized Key Removal Bypass, although in this context it applies more broadly to token renewal persistence rather than just SSH keys. The specific behavior of maintaining access after the primary identity is removed corresponds to the concept of Persistence via valid accounts or tokens where the revocation of the underlying credential does not invalidate derived sessions. Attackers leveraging this flaw can effectively bypass administrative controls designed to revoke access, turning a standard authentication flow into a backdoor that persists independently of the cluster's current authorization state.
To mitigate this risk, organizations running OpenBao must immediately upgrade to version 2.6.4 or later for the stable branch and version 2.7.1 or later for the development branch. These versions implement strict validation logic that checks the status of the Kubernetes service account against the API server during every token renewal request. If the service account has been deleted, disabled, or otherwise invalidated in Kubernetes, the OpenBao instance will reject the renewal attempt and terminate the session. Until this upgrade is performed, administrators should consider implementing external monitoring to detect unusual patterns of token renewals from identities that may have recently changed status within the cluster. Additionally, enforcing shorter TTLs for tokens issued via the Kubernetes auth method can limit the window of opportunity for attackers to exploit this flaw before administrative intervention occurs.