CVE-2026-115361

OpenBao to system zarządzania sekretami oparty na tożsamości. W wersjach przed 2.5.3, gdy usunięcie początkowej przestrzeni nazw nie powiedzie się, kolejne próby nie usuwają poprawnie wszystkich danych przed oznaczeniem przestrzeni jako usuniętej.

OpenBao to system zarządzania sekretami oparty na tożsamości. Przed wersją 2.6.0, ścieżka handleLogicalRecovery w http/logical.go porównywała token odzyskiwania o wysokich uprawnieniach ze zwykłym porównaniem równości łańcuchów. Zdalny nieuwierzytelniony atakujący, który może wysyłać powtarzane żądania trybu odzyskiwania i mierzyć czas odpowiedzi, może wywnioskować token odzyskiwania. Odzyskany token może następnie autoryzować operacje trybu odzyskiwania, które odczytują lub modyfikują dane OpenBao. Problem został naprawiony w wersji 2.6.0.

OpenBao przed wersją 2.5.2 nie wymaga potwierdzenia użytkownika podczas logowania przez JWT/OIDC z rolą ustawioną na `callback_mode=direct`. Pozwala to atakującemu na zdalny phishing poprzez nakłonienie ofiary do odwiedzenia URL i automatyczne zalogowanie jej do sesji atakującego.

OpenBao od 2.5.0 przed 2.6.2 nie egzekwuje ograniczenia allowed_ip_sans_cidr roli PKI na IP SAN pobranych z CSR, gdy włączone jest use_csr_sans. Uwierzytelnieni wywołujący z uprawnieniem sign mogą przesłać CSR z IP SAN spoza zakresu do pki/sign/<role> i uzyskać certyfikaty podpisane przez CA dla nieautoryzowanych adresów IP.

OpenBao od 2.3.0 przed 2.6.3 zawiera podatność na nieprawidłową autoryzację, która pozwala tokenom uprzywilejowanego namespace podrzędnego modyfikować rejestracje pluginów, ponieważ /v1/sys/plugins/catalog/* nie jest ograniczone do głównego namespace. Atakujący mogą usuwać istniejące rejestracje, tworzyć nieprawidłowe lub rejestrować zainstalowane pluginy przez sys/ mount namespace podrzędnego, powodując odmowę usługi.

Podatność nieprawidłowej autoryzacji w pamięci podręcznej polityk ACL OpenBao pozwala tokenom odwoływać się do polityk z dowolnych przestrzeni nazw przy użyciu specjalnie spreparowanych nazw polityk. Osoba atakująca posiadająca takie tokeny może uzyskać uprawnienia z pamięci podręcznej polityk w innych przestrzeniach nazw, w tym w przestrzeni root, i działać poza granicami przestrzeni nazw.

OpenBao przed 2.6.3 zawiera brak sprawdzenia autoryzacji, który pozwala atakującym zatrzymać usługi Agent i Proxy poprzez pominięcie nagłówka X-Vault-Header. Gdy włączone jest require_request_header, atakujący mogą wysyłać żądania przez server-side request forgery do /agent/v1/quit lub /proxy/v1/quit, aby wyłączyć te usługi.

OpenBao 2.2.0 przed 2.6.4 oraz 2.7.0 przed 2.7.1 zawiera podatność na ujawnienie informacji, która eksponuje wartość tls_acme_eab_mac_key przez endpoint sys/config/state/sanitized. Wywołujący oczyszczony endpoint konfiguracji mogą pobrać klucz MAC ACME External Account Binding używany dla certyfikatów listenera TLS, pozwalając im powiązać się z kontem ACME operatora.

OpenBao przed 2.6.4 oraz 2.7.x przed 2.7.1 nie sprawdza wygaśnięcia Secret ID przy użyciu w metodzie uwierzytelniania AppRole, pozostawiając wygasłe Secret ID ważne do czasu usunięcia ich przez okresowe tidy. Atakujący posiadający wygasły, nieposprzątany Secret ID może się zalogować i uzyskać dostęp poza jego TTL.

Podatność otwartego przekierowania w dostawcy tożsamości OIDC interfejsu OpenBao dotyczy użytkowników nieuwierzytelnionych w OpenBao. Osoba atakująca może tworzyć linki OIDC przekierowujące nieuwierzytelnionych użytkowników do celów kontrolowanych przez atakującego, umożliwiając phishing lub kradzież danych uwierzytelniających.