Katalog podatności CVE

MaxKB to open-source'owy asystent AI dla przedsiębiorstw. Przed wersją 2.10.5-lts uwierzytelnieni członkowie workspace mogą wstrzykiwać znaki kontrolne do pól access_key_id i secret_access_key AWS Bedrock, które funkcja _update_aws_credentials zapisuje do /root/.aws/credentials bez bezpiecznego parsowania. Atakujący może dopisać nowy profil AWS zawierający credential_process, a następnie wybrać go podczas późniejszej walidacji modelu, aby botocore wykonał kontrolowane przez atakującego polecenie jako root.

Wada unieważniania sesji w x-ui 0.3.2. Pełny obiekt użytkownika jest przechowywany w podpisanym cookie po stronie klienta, a uwierzytelnianie nie weryfikuje ponownie sesji w bazie danych. Zmiana nazwy użytkownika lub hasła nie unieważnia wcześniej wydanych cookie, więc atakujący z ważnym cookie może nadal korzystać z panelu administracyjnego.

Podatność nieprawidłowej kontroli dostępu w x-ui 0.3.2. Każdy uwierzytelniony użytkownik panelu może zmodyfikować szablon konfiguracji xray i wywołać restart panelu, co powoduje, że usługa gRPC zarządzania xray, domyślnie związana z loopbackiem, zostaje wygenerowana i związana z adresami nie-loopbackowymi. Rozszerza to zasięg interfejsu zarządzania poza zamierzone granice lokalne.

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.

MaxKB to open-source'owy asystent AI dla przedsiębiorstw. Przed wersją 2.10.5-lts asystenci z narzędziem, narzędziem MCP, umiejętnością lub podaplikacją używają SandboxShellBackend, który udostępnia narzędzie execute shell bez jego wykluczenia i pomija execute w interrupt_on, więc zatwierdzenie przez człowieka nie jest wymagane. Niezaufany czat lub przetworzona treść mogą zatem wywołać wykonanie polecenia; wdrożenia źródłowe z wyłączonym MAXKB_SANDBOX uruchamiają polecenia bezpośrednio jako użytkownik aplikacji, a oficjalny kontener root z opakowaniem gosu opartym na łańcuchach pozwalał na wykonanie metaznaków powłoki poza zamierzonym sandboxem.

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.

Envoy, otwartoźródłowy proxy brzegowe i usługowe, przed wersjami 1.36.10, 1.37.6, 1.38.4 i 1.39.1, ma podatność polegającą na niespójnej kanonizacji ścieżek. Gdy włączona jest opcja ignore_path_parameters_in_path_matching, router usuwa przyrostek średnika przed dopasowaniem, ale matcher RBAC url_path ocenia surową ścieżkę. Żądanie takie jak /admin;x może ominąć regułę DENY dla /admin, podczas gdy router nadal wybiera chronione backendy /admin.

W Envoy przed wersjami 1.36.10, 1.37.6, 1.38.4 i 1.39.1 normalizacja URL nie rozpoznaje segmentów ścieżki kropki i podwójnej kropki, gdy niosą parametry średnika. Żądanie takie jak /user/..;foo=bar/admin nie jest kanonizowane do /admin nawet przy włączonej normalizacji ścieżki. Jeśli upstream interpretuje segment zgodnie z RFC 3986, a Envoy stosuje routing lub RBAC do nieskróconej ścieżki, zdalny klient może wywołać zamieszanie ścieżek i obejść politykę bezpieczeństwa opartą na ścieżce.

W Envoy przed wersjami 1.36.10, 1.37.6, 1.38.4 i 1.39.1 Envoy normalnie dopasowuje surową ścieżkę żądania, podczas gdy backendy servletowe, takie jak Apache Tomcat, usuwają parametry macierzy średnika z każdego segmentu ścieżki przed rozwiązaniem zasobu. Opcja ignore_path_parameters_in_path_matching zamiast tego obcina na pierwszym średniku i nadal nie dopasowuje zachowania backendu per-segment. Zdalny klient może użyć parametryzowanego chronionego segmentu, aby Envoy wybrał niechroniony fallback, podczas gdy backend rozwiązuje chroniony zasób.

Nieprawidłowa kontrola dostępu w module HTTP API w ZLMediaKit (commit 9fd5152) umożliwia zdalne wykonanie kodu (RCE) poprzez nieuwierzytelniony dostęp do punktu API setServerConfig, który pozwala nadpisać parametr ffmpeg.snap dowolnymi poleceniami powłoki. Polecenia są następnie wykonywane przez punkt API getSnap z uprawnieniami procesu ZLMediaKit.

NotebookLM MCP, serwer MCP i usługa HTTP do interakcji z Google NotebookLM, w wersjach od 1.6.0 do 2.0.2, zawiera podatność na przechodzenie poza katalog (path traversal) w punkcie końcowym POST /batch-to-vault. Atakujący może kontrolować wartości vault_dir i slug_prefix, co pozwala na zapis plików Markdown i JSON poza zamierzonym katalogiem vault, do dowolnej lokalizacji zapisywalnej przez proces serwera.

Joplin Server przed wersją 3.7.7 z włączoną opcją TRANSCRIBE_ENABLED=true ma podatność w trasach GET/POST /api/transcribe/:id, gdzie zdekodowane ID jest przekazywane do backendów transkrypcji. Uwierzytelniony użytkownik może użyć zakodowanych w URL-u segmentów ścieżki, aby uciec z zamierzonego prefiksu /transcribe/ i uzyskać odpowiedzi z innych wewnętrznych punktów końcowych, potencjalnie ujawniając dane administracyjne, zdrowotne lub konfiguracyjne. Problem naprawiono w wersji 3.7.7.

Sync-in Server przed wersją 2.4.1 ma zauważalną różnicę czasową w punkcie końcowym logowania, ponieważ próby uwierzytelnienia dla nieistniejących kont zwracają odpowiedź bez wykonywania porównania bcrypt, które jest używane dla istniejących kont. Nieuwierzytelniony atakujący może mierzyć czasy odpowiedzi, aby enumerować prawidłowe nazwy użytkowników lub adresy e-mail, co ułatwia ataki typu credential-stuffing, password-spraying i phishing. Wersja 2.4.1 zawiera poprawkę.

Sync-in Server przed wersją 2.4.0 ma podatność w punkcie końcowym sync diff, gdzie kompiluje on ciąg znaków dostarczony przez użytkownika do wyrażenia regularnego bez walidacji złożoności. Wzorzec powodujący katastrofalne cofanie (np. ^(a+)+b) blokuje pętlę zdarzeń Node.js, czyniąc cały serwer nieodpowiedzialnym dla wszystkich użytkowników do czasu restartu kontenera. Wersja 2.4.0 naprawia ten problem.