Raw vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:LSummary
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 Steal Web Session Cookie (T1539); ranked at the 34th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SC-23 (Session Authenticity) and AC-12 (Session Termination) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
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 Data
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 Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
—
V4.4.4V7.6.2
Mitigating Controls (NIST 800-53 r5) AI
Requires protection of session authenticity, which directly stops an attacker from using a stolen or fixed session identifier after authentication.
Limits the lifetime of any session (fixed or not), thereby reducing the window during which a stolen identifier remains usable.
Enforces that only properly authorized (i.e., freshly authenticated) sessions can access resources, making a pre-existing fixed session ID unusable.
Forces re-authentication under defined conditions, which should result in issuance of a fresh session identifier and invalidation of any prior one.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Proper authentication processes must invalidate prior session identifiers to prevent fixation attacks.
Managing identities and credentials includes handling session identifiers as temporary credentials that must be invalidated on re-authentication.
Protecting and verifying identity assertions encompasses secure handling and regeneration of session tokens.
Configuration baselines can enforce session regeneration and timeout settings that block fixation.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing can detect session-fixation issues, yet the weakness absence does not replace comprehensive testing.
Access-control policy can mandate session invalidation on re-authentication, but does not prescribe the technical mechanism.
Identity-management procedures can require new session tokens after login, yet the control is broader than session handling.
Authentication-information rules can include session-token lifecycle requirements, but the control focuses on credential management.
Secure-SDLC requirement can embed session-fixation checks, but eliminating the weakness does not satisfy the full SDLC control.
Application-security requirements can specify session handling, yet the weakness fix alone does not meet the broader requirement.