CVE-2026-33757: OpenBao JWT/OIDC Auth Bypass Vulnerability

CVE-2026-33757 Overview

CVE-2026-33757 is a session fixation vulnerability in OpenBao, 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 with a role configured with callback_mode set to direct. This security gap allows an attacker to initiate an authentication request and perform "remote phishing" by tricking a victim into visiting a crafted URL, which automatically logs them into a session controlled by the attacker.

Despite being based on the authorization code flow, the direct mode calls back directly to the API, enabling an attacker to poll for an OpenBao token until it is issued. This effectively allows session hijacking through a sophisticated phishing attack vector that exploits the lack of user confirmation in the authentication flow.

Critical Impact

Attackers can hijack authentication sessions by leveraging the missing user confirmation step in JWT/OIDC direct callback mode, enabling unauthorized access to secrets managed by OpenBao.

Affected Products

• OpenBao versions prior to 2.5.2
• OpenBao instances with JWT/OIDC roles configured with callback_mode=direct
• OpenBao deployments using OIDC authentication without session confirmation enforcement

Discovery Timeline

• 2026-03-27 - CVE-2026-33757 published to NVD
• 2026-03-30 - Last updated in NVD database

Technical Details for CVE-2026-33757

Vulnerability Analysis

This vulnerability is classified as CWE-384 (Session Fixation), which occurs when an application authenticates a user without invalidating existing session identifiers, allowing an attacker to hijack authenticated sessions. In the context of OpenBao, the issue manifests specifically in the JWT/OIDC authentication mechanism when using the direct callback mode.

The vulnerability is network-accessible and requires user interaction—specifically, the victim must click on a malicious link. Once exploited, the attacker gains access to the victim's authenticated session, potentially exposing sensitive secrets stored within the OpenBao vault. The impact includes high confidentiality and integrity compromise, as attackers can read and potentially modify secrets.

Root Cause

The root cause lies in OpenBao's failure to implement a mandatory user confirmation step when processing JWT/OIDC authentication requests in direct callback mode. According to RFC 8628 Section 5.4, device authorization flows should include user confirmation screens to prevent session hijacking attacks. OpenBao's implementation bypassed this security control, allowing automatic session establishment without explicit user consent.

The direct mode was designed to callback directly to the API for convenience, but this design choice inadvertently created a security gap where attackers could pre-initialize authentication requests and have victims unknowingly complete them.

Attack Vector

The attack follows a remote phishing pattern:

1. The attacker initiates a JWT/OIDC authentication request to the vulnerable OpenBao instance
2. The attacker obtains the authentication URL and begins polling for token issuance
3. The attacker sends the authentication URL to the victim through phishing techniques
4. When the victim visits the URL, they are automatically authenticated without confirmation
5. The attacker receives the token through their polling mechanism, gaining access to the victim's session

The security patch adds a confirmation screen for direct type logins that requires manual user interaction and displays the requester's IP address to complete authentication:

// the device flow code
deviceCode string

// requesterIP is the remote address of the client that called authURL, so that it can be displayed
// on the confirmation page (RFC 8628 5.4)
requesterIP string

Source: GitHub Commit e321039

Detection Methods for CVE-2026-33757

Indicators of Compromise

• Multiple JWT/OIDC authentication requests originating from different IP addresses but completing sessions for the same user
• Unusual polling patterns against the OpenBao authentication API endpoints
• Authentication completions where the initiating IP differs from the completing IP
• Increased phishing emails or messages containing OpenBao authentication URLs

Detection Strategies

• Monitor OpenBao audit logs for JWT/OIDC authentication events with callback_mode=direct
• Implement network-level detection for suspicious authentication URL patterns being shared externally
• Correlate authentication initiation events with completion events to identify IP address mismatches
• Review identity provider logs for unusual authorization code flow activity targeting OpenBao Client IDs

Monitoring Recommendations

• Enable comprehensive audit logging on all OpenBao instances
• Configure alerts for authentication events where the session initiator differs from the session completer
• Monitor for bulk authentication URL generation that could indicate reconnaissance activity
• Implement rate limiting on authentication endpoints to slow potential attacks

How to Mitigate CVE-2026-33757

Immediate Actions Required

• Upgrade OpenBao to version 2.5.2 or later immediately
• Audit all JWT/OIDC roles and identify those configured with callback_mode=direct
• Review recent authentication logs for signs of exploitation
• Notify users who may have clicked on suspicious authentication links

Patch Information

OpenBao has released version 2.5.2 which includes an additional confirmation screen for direct type logins. This screen requires manual user interaction and displays the requester's IP address (per RFC 8628 Section 5.4) before completing authentication. The fix is available in GitHub Commit e321039. For complete details, refer to the GitHub Security Advisory GHSA-7q7g-x6vg-xpc3.

Workarounds

• Remove any JWT/OIDC roles configured with callback_mode=direct and switch to alternative callback modes
• Enforce confirmation for every session on the token issuer side for the Client ID used by OpenBao
• Implement additional access controls such as IP allowlisting for authentication endpoints
• Educate users about the risks of clicking on authentication URLs received through unsolicited communications

# Configuration example - List roles with direct callback mode for audit
bao list auth/oidc/role

# Check individual role configuration
bao read auth/oidc/role/<role_name>

# Update role to remove direct callback mode (if alternative is acceptable)
bao write auth/oidc/role/<role_name> callback_mode="client"