OIDC direct-callback flaw enables OpenBao token theft

TL;DR — OpenBao’s OIDC/JWT login in callback_mode=direct can be abused for “remote phishing,” issuing an OpenBao token into an attacker-controlled session when a victim visits a crafted login URL.

What happened

OpenBao is an open-source, identity-based secrets management system (Vault-like) used to broker access to credentials and other sensitive secrets.

CVE-2026-33757 describes a missing user-confirmation step in the JWT/OIDC auth login flow when a role is configured with callback_mode=direct. An attacker can initiate an authentication request, convince a victim to open the URL, and have the victim automatically complete login into the attacker’s session; the attacker can then poll until an OpenBao token is issued.

This is a high-impact “auth UX” failure mode: it doesn’t require a memory corruption exploit, but it targets the control plane of a secrets system—exactly the kind of component platform teams depend on for blast-radius reduction.

Who is impacted

• OpenBao installations with a JWT/OIDC auth method enabled.
• Any configuration using a role with callback_mode=direct.
• Versions < 2.5.2 (per CVE record).

What to do now

• Follow vendor remediation guidance and apply the latest patched release available at the time of writing.

  "Version 2.5.2 includes an additional confirmation screen for direct type logins that requires manual user interaction in order to finish the authentication."

• If you cannot patch immediately, apply the vendor workarounds to remove the vulnerable login mode:

  "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"

• Treat this as a potential token-issuance exposure if you have public or broadly reachable OpenBao UI/API endpoints: review auth logs for unexpected direct-mode login activity and rotate any credentials reachable via OpenBao policies tied to impacted auth roles.