CVE-2026-33757
Published: 27 March 2026
Summary
CVE-2026-33757 is a critical-severity Session Fixation (CWE-384) vulnerability in Openbao Openbao. Its CVSS base score is 9.6 (Critical).
Operationally, exploitation aligns with the MITRE ATT&CK technique Spearphishing Link (T1566.002); ranked at the 28.8th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified are NIST 800-53 CM-6 (Configuration Settings) and SI-2 (Flaw Remediation).
Deeper analysis
CVE-2026-33757 affects OpenBao, an open-source identity-based secrets management system, in versions prior to 2.5.2. The vulnerability arises during JWT/OIDC authentication when a role is configured with `callback_mode` set to `direct`. In this mode, OpenBao fails to prompt users for confirmation before completing the login process. Although based on the authorization code flow, the `direct` mode bypasses typical redirects by calling back directly to the OpenBao API, enabling polling for authentication tokens. This issue is classified under CWE-384 (Session Fixation) with a CVSS v3.1 base score of 9.6 (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:L).
An attacker can exploit this vulnerability remotely without privileges by initiating an authentication request tied to a `direct` mode role. The attacker then tricks a victim into visiting a crafted URL, which automatically authenticates the victim into the attacker's session upon page load—a form of remote phishing. By polling the OpenBao API, the attacker obtains a valid token associated with the victim's credentials, granting high confidentiality and integrity impact, such as access to managed secrets.
The official patch in OpenBao version 2.5.2 introduces a confirmation screen for `direct` type logins, requiring manual user interaction to complete authentication. Workarounds include removing roles with `callback_mode=direct` or configuring the token issuer to enforce confirmation for every session using the OpenBao Client ID. Details are available in the GitHub security advisory (GHSA-7q7g-x6vg-xpc3) and the fixing commit (e32103951925723e9787e33886ab6b6ec20f4964), with additional context in RFC 8628 section 5.4 on OAuth 2.0 incremental authorization.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-16624
Vulnerability details
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…
more
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.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise TechniquesAI
Why these techniques?
The CVE enables a phishing attack via crafted authentication URLs (T1566.002) that exploits session fixation in direct callback_mode OIDC/JWT flows, allowing an attacker to obtain valid application access tokens tied to the victim's identity (T1528) without further interaction.
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST 800-53 r5) AI
Flaw remediation directly mitigates CVE-2026-33757 by applying the patch in OpenBao version 2.5.2 that adds a confirmation screen for direct mode logins.
Secure configuration settings prevent the vulnerability by removing or disabling roles with callback_mode=direct as a documented workaround.
Managing identity providers and authorization servers enables enforcement of user confirmation on the token issuer side for the OpenBao Client ID, aligning with the recommended workaround.