3.1

CVSS Score

3.1

-

CVSS Score

Basic Information

Concerned about an active attack path?

Talk to our security experts and see Miggo in action.

Miggo Vulnerability Database

→

CVE-2026-39388

CVE-2026-39388: OpenBao's Certificate Authentication Allows Token Renewal With Different Certificate

Background

OpenBao's Certificate authentication method, when a token renewal is requested and disable_binding=true is set, attempts to verify the current request's presented mTLS certificate matches the original. Token renewals for other authentication methods do not require any supplied login information.

Impact

Due to incorrect matching, the certificate authentication method would allow renewal of tokens for which the attacker had a sibling certificate+key signed by the same CA, but which did not necessarily match the original role or the originally supplied certificate. This implies an attacker could still authenticate to OpenBao in a similar scope, however, token renewal implies that an attacker may be able to extend the lifetime of dynamic leases held by the original token. This attack requires knowledge of either the original token or its accessor.

This vulnerability is originally from HashiCorp Vault.

Patches

This has been addressed in v2.5.3.

Workarounds

Ensure privileged roles are tightly scoped to single certificates.

(GitHub Advisory)

Miggo Vulnerability Database

→

CVE-2026-39388

CVE-2026-39388:

3.1

CVSS Score

3.1

-

CVSS Score

Basic Information

Is this CVE running in your environment?

Easily map the attack path and prioritize which CVEs are a threat to your organization

Validate Exposure

Technical Details

Package Name	Ecosystem	Vulnerable Versions	First Patched Version
github.com/openbao/openbao	go	< 0.0.0-20260420160924-abe84e1af4c3	0.0.0-20260420160924-abe84e1af4c3

Technical Details

Vulnerability Intelligence
Miggo AI

Root Cause Analysis

The vulnerability lies in OpenBao's certificate authentication method, specifically during the token renewal process. The root cause was an improper and weak validation check in the backend.pathLoginRenew function. When a token renewal was requested, the system attempted to verify that the client certificate presented matched the one used for the original authentication. However, instead of comparing the full certificates, it only compared the 'subject_key_id' and 'authority_key_id'. This is insecure because it's possible for an attacker to obtain a different certificate (a 'sibling' certificate) issued by the same Certificate Authority that would pass this check. This would allow the attacker to renew a token that did not belong to them, thereby extending their access and the lifetime of any dynamic leases associated with the token. The fix involved two main changes. First, the backend.pathLogin function was updated to store the complete raw certificate in the token's internal data upon initial login. Second, the backend.pathLoginRenew function was changed to discard the weak key ID check and instead perform a direct, constant-time comparison between the stored raw certificate and the one presented during the renewal request. This ensures that only the exact same certificate that was used for the initial login can be used for renewal.

Vulnerable functions

backend.pathLoginRenew

builtin/credential/cert/path_login.go

The vulnerability exists in the `pathLoginRenew` function, which is responsible for handling token renewals for the certificate authentication method. The original implementation incorrectly verified the client's identity by only checking the `subject_key_id` and `authority_key_id` of the presented certificate. This check was insufficient because different certificates signed by the same Certificate Authority (CA) could share the same `authority_key_id`, and potentially the same `subject_key_id` if not unique. This allowed an attacker with a sibling certificate (a different certificate from the same CA) to renew a token they did not originally own, extending the lifetime of any associated dynamic leases. The patch fixes this by storing the entire raw certificate during the initial login and then performing a constant-time comparison of the raw certificate during renewal, ensuring the same exact certificate is used.

Vulnerability Intelligence
Miggo AI

Unlock WAF rules for this CVE

Generate vendor-ready rules for the observed attack patterns, plus reasoning and safe deployment guidance

Get WAF rules

WAF Protection Rules

WAF Rule

W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.

Reasoning

*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.