Bug 2452269 (CVE-2026-33757)

Summary: CVE-2026-33757 OpenBao: lack of user confirmation for OpenBao OIDC direct callback mode
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security DevOps Team <prodsec-dev>
Status: NEW --- QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: aazores, cmah, eaguilar, ebaron, jolong, pjindal
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in OpenBao. A missing prompt for user confirmation when logging in via the JWT/OIDC authentication method with a role configured to use `callback_mode=direct` allows an attacker to initiate an authentication request and perform a "remote phishing" attack by tricking an authenticated user into visiting a crafted URL, automatically logging the user into the session of the attacker.
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2452353, 2452351, 2452352    
Bug Blocks:    

Description OSIDB Bzimport 2026-03-27 15:02:16 UTC
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.