Vulnerability from bitnami_vulndb
Published
2026-07-27 05:49
Modified
2026-07-27 06:08
Summary
OpenBao lacks user confirmation for OIDC direct callback mode
Details

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.

To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Bitnami",
        "name": "openbao",
        "purl": "pkg:bitnami/openbao"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.5.2"
            }
          ],
          "type": "SEMVER"
        }
      ],
      "severity": [
        {
          "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:L",
          "type": "CVSS_V3"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33757"
  ],
  "database_specific": {
    "cpes": [
      "cpe:2.3:a:openbao:openbao:*:*:*:*:*:*:*:*"
    ],
    "severity": "High"
  },
  "details": "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.",
  "id": "BIT-openbao-2026-33757",
  "modified": "2026-07-27T06:08:49.409Z",
  "published": "2026-07-27T05:49:03.835Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-33757"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2452269"
    },
    {
      "type": "WEB",
      "url": "https://datatracker.ietf.org/doc/html/rfc8628#section-5.4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openbao/openbao/commit/e32103951925723e9787e33886ab6b6ec20f4964"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openbao/openbao/security/advisories/GHSA-7q7g-x6vg-xpc3"
    },
    {
      "type": "WEB",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33757"
    },
    {
      "type": "WEB",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-33757.json"
    }
  ],
  "schema_version": "1.6.2",
  "summary": "OpenBao lacks user confirmation for OIDC direct callback mode"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.