CVE-2026-79918

W MaxKB przed wersją 2.10.6-lts kod biblioteki funkcji działający w sandboxie LD_PRELOAD może wywołać ctypes.CDLL z callbacku importlib.abc.MetaPathFinder, tak aby heurystyka stosu wywołań dlopen zobaczyła ramkę importu Pythona, a następnie użyć niepodpiętego dlsym z RTLD_NEXT do rozwiązania prawdziwego wywołania systemowego glibc i obejścia czarnej listy wywołań systemowych sandboxa.

W MaxKB w wersjach 2.7.0 do 2.10.4-lts endpoint POST /chat/api/{application_id}/chat/{chat_id}/share_chat sprawdza jedynie istnienie konwersacji, ale nie weryfikuje, czy należy ona do uwierzytelnionego chat_user_id ani do aplikacji powiązanej z tokenem wywołującego. Atakujący z dowolnym tokenem czatu i znanym chat_id ofiary może utworzyć publiczny link ChatShareLink ujawniający konwersację oraz stan PublicFileAccess umożliwiający pobranie powiązanych plików bez poświadczeń, bez możliwości cofnięcia.

W MaxKB w wersji 2.10.2-lts i wcześniejszych trasy zarządzania rekordami czatu autoryzują application_id ze ścieżki, ale ładują rekordy używając globalnych wartości chat_id i chat_record_id bez potwierdzenia, że czat należy do autoryzowanej aplikacji. Zwykły użytkownik w tym samym workspace, znając chat_id utrwalonego rekordu ofiary, może odczytać rekordy czatu ofiary, a także skopiować odpowiedzi ofiary poprzez add_knowledge.

MaxKB, asystent AI dla przedsiębiorstw, w wersji 2.10.3-lts i wcześniejszych, ma podatność w trasie formularza parametrów modelu. Uwierzytelniony użytkownik z uprawnieniami do odczytu modelu w przestrzeni kontrolowanej przez atakującego może odczytać lub nadpisać model_params_form ofiary w innej przestrzeni, używając znanego model_id, bez uwzględnienia workspace_id w zapytaniu.

W MaxKB w wersji 2.10.3-lts i wcześniejszych import i synchronizacja dokumentów web przekazuje URL uwierzytelnionego użytkownika do Fork.fork, który wywołuje requests.get z verify=False i bez ograniczeń schematów, adresów loopback, link-local, prywatnych ani zarezerwowanych. Treść odpowiedzi staje się treścią importowanego dokumentu, co pozwala niskouprzywilejowanemu użytkownikowi na odczyt metadanych chmury lub wewnętrznych usług HTTP przez serwer MaxKB.

W MaxKB w wersji 2.10.2-lts i wcześniejszych zwykły użytkownik w tym samym workspace może uzyskać application_id innego użytkownika z endpointu rankingu pytań aplikacji na stronie głównej, gdy opublikowana aplikacja ofiary ma aktywność rankingową w wybranym zakresie dat. Atakujący mogący tworzyć i publikować aplikacje workflow może umieścić ujawniony identyfikator w węźle aplikacji workflow, uruchomić go, otrzymać dane wyjściowe ofiary i utworzyć trwałe rekordy application_chat pod aplikacją ofiary.

W MaxKB w wersji 2.10.2-lts i wcześniejszych ścieżka uwierzytelniania /chat/api/mcp wyszukuje ApplicationApiKey tylko po sekrecie i statusie aktywności, bez egzekwowania sprawdzeń is_permanent i expire_time używanych przez standardowe API czatu. Wcześniej ważny, niepermanentny klucz aplikacji, który pozostaje aktywny po wygaśnięciu, może zainicjować endpoint MCP, wyświetlić metadane narzędzi opublikowanej aplikacji, wywołać tools/call i utworzyć trwałe rekordy application_chat.

W MaxKB w wersji 2.10.2-lts i wcześniejszych zwykły użytkownik workspace znający tool_id aktywnego narzędzia MCP innego użytkownika może pobrać ukryte narzędzie przez trasę szczegółów narzędzia, która nie stosuje autoryzacji per-zasób używanej przez trasę listy. Odpowiedź zawiera Tool.code, który może zawierać konfigurację serwera MCP i nagłówki, a atakujący mogący tworzyć lub edytować własny workflow może umieścić obcy mcp_tool_id w węźle mcp workflow, aby debug użył konfiguracji MCP właściciela.

W MaxKB od wersji 2.0.0 do 2.10.2-lts trasy operacji na dokumentach i akapitach autoryzują tylko knowledge_id ze ścieżki żądania, a następnie pobierają Document po document_id lub Paragraph po paragraph_id bez potwierdzenia, że obiekt należy do tej bazy wiedzy. Zwykły użytkownik workspace znający UUID dokumentu lub akapitu ofiary może odczytać lub zmodyfikować treść w bazie wiedzy innego użytkownika.

W MaxKB od wersji 2.0.0 do 2.9.2 najniższy rangą członek workspace, któremu odmówiono dostępu do narzędzia przez WorkspaceUserResourcePermission, może nadal powiązać jego identyfikator przez tool_ids, skill_tool_ids lub mcp_tool_ids i wykonać je przez ścieżkę dyspozycji agenta lub workflow. Ścieżka dyspozycji nie stosuje ponownie uprawnień per-narzędzie, a wykonanie narzędzia odszyfrowuje init_params po stronie serwera, co pozwala wywołującemu otrzymać poświadczenia przenoszone przez zabronione narzędzie.