CVE-2026-33757

OpenBao: zdalne phishing przez JWT/OIDC bez potwierdzenia logowania

CVSS 9.6v3.1pub. 2026-03-27upd. 2026-06-30

OpenBao przed wersją 2.5.2 nie wymaga potwierdzenia od użytkownika podczas logowania przez JWT/OIDC z trybem callback_mode=direct, co umożliwia atakującemu przejęcie sesji ofiary. Podatność pozwala na przeprowadzenie tzw. remote phishing, w wyniku którego ofiara nieświadomie uwierzytelnia się w sesji kontrolowanej przez atakującego.

▸ Pokaż oryginał (EN)

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.

🤖 Analiza AI

Jak działa

Atakujący inicjuje żądanie uwierzytelnienia JWT/OIDC dla roli z ustawionym parametrem callback_mode=direct. Następnie przekonuje ofiarę do odwiedzenia odpowiednio spreparowanego URL, który automatycznie kończy proces logowania bez żadnego kroku wymagającego interakcji użytkownika. W trybie direct wywołanie zwrotne trafia bezpośrednio do API OpenBao, co pozwala atakującemu cyklicznie odpytywać API (polling) o wydanie tokenu OpenBao aż do jego uzyskania. Atakujący przejmuje w ten sposób token uwierzytelniający ofiary bez jej wiedzy.

Skutki

Atakujący może uzyskać token OpenBao uwierzytelniony jako ofiara, co daje mu dostęp do zarządzanych sekretów i zasobów z uprawnieniami skompromitowanego konta, potencjalnie prowadząc do ujawnienia poufnych danych i naruszenia integralności systemu.

Mitygacja

Należy zaktualizować OpenBao do wersji 2.5.2, która wprowadza dodatkowy ekran potwierdzenia dla logowań w trybie direct wymagający ręcznej interakcji użytkownika. Jako obejście można usunąć wszystkie role z callback_mode=direct lub wymusić potwierdzenie każdej sesji po stronie wystawcy tokenów (token issuer) dla Client ID używanego przez OpenBao.

Kogo dotyczy

OpenBao (openbao/openbao) we wszystkich wersjach przed 2.5.2, gdy skonfigurowane są role z parametrem callback_mode=direct dla JWT/OIDC

Uwagi

Podatność dotyczy wyłącznie konfiguracji z JWT/OIDC i rolami używającymi callback_mode=direct. Mechanizm ataku jest zbliżony do Device Authorization Grant opisanego w RFC 8628 sekcja 5.4.