CVE-2026-105138

Obot 0.26.0 przed 0.26.2 zawiera podatność umożliwiającą ominięcie autoryzacji, która pozwala uwierzytelnionym użytkownikom pasującym do dowolnego profilu vMCP na dostęp do promptów i zasobów nieprzyznanych komponentów. Ponieważ profile były egzekwowane tylko dla narzędzi, atakujący mogą uzyskać dostęp do promptów, zasobów i szablonów zasobów przez połączenie współdzielonego komponentu właściciela vMCP.

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.