CVE-2026-33757: OpenBao lacks user confirmation for OIDC direct callback mode
OpenBao is an open source identity-based secrets management system. Prior to version 2.5.2, OpenBao does not prompt for user confirmation when logging in via JWT/OIDC and a role with `callback_mode` set to `direct`. This allows an attacker to start an authentication request and perform "remote phishing" by having the victim visit the URL and automatically log-in to the session of the attacker. Despite being based on the authorization code flow, the `direct` mode calls back directly to the API and allows an attacker to poll for an OpenBao token until it is issued. Version 2.5.2 includes an additional confirmation screen for `direct` type logins that requires manual user interaction in order to finish the authentication. This issue can be worked around either by removing any roles with `callback_mode=direct` or enforcing confirmation for every session on the token issuer side for the Client ID used by OpenBao.
Security readout for executives and security teams
Plain-English summary
OpenBao versions before 2.5.2 can let a phished user unknowingly complete login into an attacker-controlled session when JWT/OIDC direct callback mode is enabled. Because OpenBao protects secrets, a stolen token could create serious confidentiality and integrity risk depending on assigned policies.
Executive priority
Treat as urgent for environments using OpenBao OIDC/JWT login. Prioritize secrets-management platforms because compromised tokens can expose sensitive systems. Confirm whether direct callback roles exist before assuming exposure.
Technical view
The issue affects OpenBao before 2.5.2 when a JWT/OIDC role uses callback_mode=direct. Direct callback mode did not require user confirmation, allowing remote phishing where a victim completes authentication and OpenBao issues a token to the attacker's pending session. Version 2.5.2 adds a manual confirmation screen.
Likely exposure
Exposure is limited to OpenBao deployments before 2.5.2 with JWT/OIDC roles configured with callback_mode=direct. Impact depends on the victim's OpenBao policies and token privileges. The source bundle does not identify affected downstream packages beyond OpenBao.
Exploitation context
The vulnerability is network reachable, low complexity, and requires user interaction. The provided sources do not show CISA KEV listing or confirmed active exploitation. The described attack is phishing-based rather than unauthenticated direct token theft.
Researcher notes
This is mapped to CWE-384 and resembles session binding failure in an authorization-code-style flow. RFC8628 section 5.4 is referenced for user confirmation expectations. The fix adds confirmation for direct logins; review commit e32103951925723e9787e33886ab6b6ec20f4964 for implementation detail.
Mitigation direction
Upgrade OpenBao to version 2.5.2 or later.
Remove or disable roles using callback_mode=direct.
Enforce issuer-side confirmation for every OpenBao Client ID session.
Review vendor and downstream guidance for package-specific remediation status.
Validation and detection
Inventory OpenBao deployments and confirm versions are 2.5.2 or later.
Review JWT/OIDC auth roles for callback_mode=direct.
Confirm direct-mode login presents a manual confirmation screen.
Check identity provider policy for mandatory confirmation on the OpenBao client.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-384: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
The CVE wording references authentication or credential exposure, so valid-account and credential-access review may help. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
2CVSS vectors
5Timeline events
2ADP providers
7Source links
SSVC decision data
CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: noneAutomatable: noTechnical Impact: total
CVSS vector scores
2 official scores
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-384 · source CWE mapping
Session Fixation
Session Fixation represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.