GHSA-gf3j-hm38-jhh5: OpenBao before 2.6.4 and 2.7.0 before 2.7.1 Kubernetes Auth Method Token Renewal After Revocation

Q: Who is exposed to this issue?

Deployments using OpenBao's Kubernetes Auth method are exposed if they run a version before 2.6.4, or a 2.7.x version before 2.7.1. An attacker must already hold an authenticated token issued through that auth method.

Q: What does an attacker need to do to maintain access?

The attacker needs a Kubernetes Auth method token obtained while the associated service account token was valid. They can renew that token even after the Kubernetes service account has been deleted, allowing continued access.

Q: Does deleting the Kubernetes service account revoke previously issued OpenBao tokens?

Not on affected versions when the token was issued through the Kubernetes Auth method and is renewed. OpenBao does not verify during renewal that the original Kubernetes service account token remains valid.

Published Oct 22, 2026

Updated

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.

Affected Software

2 affected componentsFixes available

bitnami/openbao<2.6.4

2.6.4

bitnami/openbao>=2.7.0<2.7.1

2.7.1

Remediation

Recommended actions to resolve this vulnerability, in priority order.

Upgrade
Upgrade bitnami/openbao to a version that resolves this vulnerability.
Fixed in 2.6.4
Upgrade
Upgrade bitnami/openbao to a version that resolves this vulnerability.
Fixed in 2.7.1

Event History

Oct 22, 2026

CVE Published

via OSV·07:13 PM

Data Sourced

via OSV·07:13 PM

DescriptionSeverityWeakness

Oct 29, 2026

Advisory Published

via OSV·08:54 AM

Data Sourced

via OSV·08:54 AM

Affected Software

Frequently Asked Questions

Who is exposed to this issue?

Deployments using OpenBao's Kubernetes Auth method are exposed if they run a version before 2.6.4, or a 2.7.x version before 2.7.1. An attacker must already hold an authenticated token issued through that auth method.

What does an attacker need to do to maintain access?

The attacker needs a Kubernetes Auth method token obtained while the associated service account token was valid. They can renew that token even after the Kubernetes service account has been deleted, allowing continued access.

Does deleting the Kubernetes service account revoke previously issued OpenBao tokens?

Not on affected versions when the token was issued through the Kubernetes Auth method and is renewed. OpenBao does not verify during renewal that the original Kubernetes service account token remains valid.

GHSA-gf3j-hm38-jhh5: OpenBao before 2.6.4 and 2.7.0 before 2.7.1 Kubernetes Auth Method Token Renewal After Revocation

Affected Software

Remediation

Event History

Frequently Asked Questions

Who is exposed to this issue?

What does an attacker need to do to maintain access?

Does deleting the Kubernetes service account revoke previously issued OpenBao tokens?

Company

Resources

Contact

Frequently Asked Questions

Who is exposed to this issue?

What does an attacker need to do to maintain access?

Does deleting the Kubernetes service account revoke previously issued OpenBao tokens?