CVE-2026-105139

Obot 0.12.0 przed 0.26.2 zawiera podatność niewystarczającej ochrony poświadczeń, która pozwala uwierzytelnionym użytkownikom na odczyt statycznych sekretów ustawionych na wpisach katalogu MCP przez administratorów lub zaawansowanych użytkowników. Podstawowi użytkownicy, którym przyznano wpis przez reguły kontroli dostępu, mogą wysłać żądanie GET /api/all-mcps/entries/{entry_id}, aby uzyskać klucze API lub tokeny w postaci jawnego tekstu i nadużyć ich wobec usług zaplecza.

Obot w wersjach od 0.21.1 do 0.24.1 zawiera podatność na obejście autoryzacji, która pozwala uwierzytelnionym użytkownikom na dostęp do serwerów MCP, ponieważ lista deny w checkUI pomija trasę /mcp-connect-composite/. Użytkownicy z podstawową rolą i złożonym identyfikatorem MCP mogą przekazywać żądania przez mcpGateway.Proxy, aby wywoływać narzędzia na serwerach MCP objętych regułami kontroli dostępu.

Wersje obot przed v0.21.1 nie egzekwują reguł kontroli dostępu na punkcie końcowym /mcp-connect, co pozwala każdemu uwierzytelnionemu użytkownikowi na połączenie z ograniczonymi serwerami MCP, jeśli zna ich identyfikator. Atakujący mogą ominąć autoryzację i uzyskać dostęp do wrażliwych systemów zaplecza.

Obot w wersjach do commit d7e6970 włącznie, gdy uruchamiany jest przez szybki start Docker z README, nasłuchuje na 0.0.0.0:8080 z wyłączonym uwierzytelnianiem. Każde żądanie jest mapowane na syntetycznego użytkownika 'nobody' z rolami Owner i Admin, co daje pełny dostęp administracyjny do API i UI Obot. Dodatkowo montowany jest /var/run/docker.sock, co daje dostęp do kontroli Docker hosta.

Obot przed wersją 0.26.0 zawiera podatność obejścia uwierzytelniania w przepływie logowania CLI, która pozwala nieuwierzytelnionym atakującym ukraść klucze API poprzez wybór identyfikatorów żądań tokenów. Atakujący może utworzyć żądanie tokenu przez POST /api/token-request, wysłać link logowania zalogowanemu użytkownikowi i pobrać wynikowy nie wygasający klucz API, aby przejąć konto ofiary.

Obot 0.25.0 przed 0.25.6 oraz 0.26.0 przed 0.26.1 zawiera wyścig w odświeżaniu grup dostawcy uwierzytelniania, który może przywrócić członkostwa w grupach właśnie odebrane w dostawcy tożsamości. Gdy nakładające się odświeżenia dla tego samego użytkownika są zatwierdzane w złej kolejności, nieaktualne członkostwa są utrwalane i użytkownik zachowuje odebrany dostęp oparty na grupach przez około dziesięć minut.

Obot przed v0.23.0 zawiera podatność na SSRF w rejestracji zdalnych serwerów MCP, która pozwala uprzywilejowanym użytkownikom na podawanie dowolnych adresów URL bez walidacji. Atakujący z rolą Power User lub wyższą mogą zmusić Obot do wysyłania żądań do wewnętrznych usług i punktów końcowych metadanych chmury, odczytując odpowiedzi w komunikatach błędów i ujawniając wrażliwe dane uwierzytelniające.

Obot w wersjach przed v0.23.0 nie wymusza uwierzytelniania na endpointach MCP Registry pod /v0.1/*, gdy uwierzytelnianie rejestru jest włączone. Nieuwierzytelniony atakujący może odczytać metadane rejestru, w tym nazwy serwerów, opisy, adresy URL repozytoriów i adresy URL połączeń, wysyłając żądania GET do /v0.1/servers.

Obot przed v0.23.0 (dotknięte wersje <= v0.22.1) z włączonym uwierzytelnianiem (OBOT_SERVER_ENABLE_AUTHENTICATION=true) udostępnia dynamiczną rejestrację klientów OAuth bez uwierzytelnienia i bez ograniczeń URI przekierowań. Atakujący może zarejestrować klienta wskazującego na jego domenę i przechwycić kod autoryzacyjny zalogowanego użytkownika, a następnie wymienić go na tokeny dostępu i odświeżania. Tokeny MCP OAuth niosą pełny zestaw grup ofiary w JWT, a Obot waliduje tylko issuer, nie audience, co pozwala na użycie tokena jako bearer do dowolnych endpointów API Obot, do których ofiara ma dostęp.