FlawAtlas
Search the atlas
CVE-2026-33757 Critical

OpenBao lacks user confirmation for OIDC direct callback mode

### Impact 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. ### Patches Version 2.5.2 includes an additional confirmation screen for `direct` type logins that requires manual user interaction in order to finish the authentication. ### Workarounds 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.

Exploit probability 0.4%
Published March 26, 2026
Required by Not available
Last source change July 27, 2026

02 / AFFECTED SOFTWARE

Affected packages

Unknown Unknown

131 explicit affected versions

Bitnami openbao
Go github.com/openbao/openbao
Go github.com/openbao/openbao

03 / CONNECTIONS

Connected vulnerabilities

related OPENSUSE-SU-2026:21483-1

04 / EVIDENCE

Source records

Open Source Vulnerabilities GHSA-7q7g-x6vg-xpc3

### Impact 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. ### Patches Version 2.5.2 includes an additional confirmation screen for `direct` type logins that requires manual user interaction in order to finish the authentication. ### Workarounds 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.

View original source
Open Source Vulnerabilities GO-2026-4860

OpenBao lacks user confirmation for OIDC direct callback mode in github.com/openbao/openbao

View original source
Open Source Vulnerabilities CVE-2026-33757

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.

View original source
Open Source Vulnerabilities BIT-openbao-2026-33757

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.

View original source

05 / REFERENCES

Further evidence