Live › vulnerability › CVE-2026-115356
Go to dashboardOpenBao does not re-check the originating Kubernetes service account token when renewing a token issued by the Kubernetes auth method. An attacker who already holds such a token can keep renewing it and retain access after the service account has been deleted.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Teams running OpenBao with the Kubernetes auth method enabled, where workloads authenticate using Kubernetes service account tokens. Deployments that do not use the Kubernetes auth method are not exposed through this flaw.
No product ranges from the sources yet.
bao versionbao auth list2.6.4 or later on the 2.6 line, or to 2.7.1 or later on the 2.7 lineEach row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-115356")
NVD data is provided by NIST and is public domain · EPSS scores by FIRST, used with attribution. Posts quoted belong to their authors.