CVE-2026-71543

OpenBao Agent w trybie renderowania exec mógł zapisywać sekrety z env_template na standardowe wyjście, gdy plik exec.go odtwarzał runner szablonu po powtarzających się błędach renderowania, głównie po osiągnięciu num_retries. Proces nadzorujący, kolektor logów lub lokalny użytkownik z dostępem do tego wyjścia mógł odczytać wyrenderowane wartości sekretów. Problem naprawiono w wersji 2.6.0.

OpenBao przed wersją 2.6.0 ma podatność w vault/policy/acl.go, gdzie szerszy wildcard ACL może być oceniany przed bardziej specyficznymi ścieżkami z trailing-wildcard i capabilities = ["deny"] dla operacji LIST. Gdy ścieżka nadrzędna zezwalała na LIST, a podrzędna była zabroniona, można było listować zabronioną ścieżkę.

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 przed wersją 2.5.5 ma podatność, w której uwierzytelniony użytkownik z dostępem do zapisu do transit/keys/* może spowodować zakończenie procesu serwera, ustawiając derived na true przy typie klucza rsa-, ecdsa- lub ed25519. Błąd w obsłudze mutexa prowadzi do paniki, braku odpowiedzi HTTP i odmowy usługi.

OpenBao przed wersją 2.5.5 pozwala użytkownikom z uprawnieniami do /sys/namespaces/root w nie-rootowej przestrzeni nazw wykorzystać specjalne traktowanie ścieżki root w kanonizacji przestrzeni nazw. Kontrole ACL odbywają się przed kanonizacją root do pustej ścieżki, przez co /sys/namespaces/root rozwiązuje się do przestrzeni nazw zawierającej backend systemowy, umożliwiając dozwolone operacje wyszukiwania, usuwania, blokowania lub zmiany metadanych na tej przestrzeni.

OpenBao przed wersją 2.5.5 pozwala użytkownikowi z dostępem do sys/leases/revoke/:lease_id w jednej przestrzeni nazw unieważnić lease w innej przestrzeni nazw, jeśli zna identyfikator obcego lease. Routing wyszukiwania lease w vault/expiration.go pozwala FetchLeaseInfo i loadEntry rozwiązać dane lease poza przestrzenią nazw żądania, umożliwiając jednemu tenantowi unieważnienie lease i poświadczeń innego tenanta.

OpenBao przed wersją 2.5.5 używa funkcji EscapeLDAPValue (do escapowania DN wg RFC 4514) tam, gdzie wymagane jest escapowanie filtrów wyszukiwania LDAP (RFC 4515) w GetUserDN. Przy skonfigurowanym backendzie LDAP dla Active Directory, nazwa użytkownika zawierająca metaznaki filtrów może zmienić predykat wyszukiwania i wybrać inny wpis, co pozwala na powiązanie tokena z inną tożsamością i dostęp do jej sekretów.

OpenBao przed wersją 2.5.4 ma podatność w metodzie uwierzytelniania Kerberos, gdzie odpowiedź na żądanie GET lub z nagłówkiem Authorization: Negotiate zawiera obiekt logical.Auth wraz z komunikatem o błędzie. Powoduje to tworzenie tokenów z domyślną polityką, domyślnym TTL i bez informacji o encji, które są ukryte przez komunikat błędu. Tokeny nie są dostępne dla wywołującego ani poza sys/raw.