Katalog podatności CVE

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.

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.

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.

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.

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.

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.

Joplin Server przed wersją 3.7.2 ma podatność w trasie GET /items/:id/content, która ładuje treść elementu na podstawie wewnętrznego ID serwera dostarczonego przez atakującego, bez sprawdzania, czy zalogowany użytkownik jest właścicielem lub ma dostęp do tego elementu. Każdy uwierzytelniony użytkownik, który uzyska lub zgadnie ID elementu innego użytkownika, może odczytać odpowiednią notatkę lub treść elementu, jeśli nie jest chroniona szyfrowaniem end-to-end. Problem naprawiono w wersji 3.7.2.

Stencil core 4.43.5 zawiera podatność DOM-based cross-site scripting (XSS) w komponencie runtime. Gdy aplikacja korzysta z eksperymentalnej opcji slot fixes i używa komponentów scoped, przypisanie ciągu znaków do właściwości textContent elementu hosta powoduje, że wartość jest interpretowana jako HTML zamiast tekstu. Jeśli aplikacja zapisuje dane kontrolowane przez atakującego do tych elementów, dane mogą być interpretowane jako znaczniki i skrypt może wykonać się w kontekście pochodzenia aplikacji.

Stencil core 4.43.5 jest podatny na nieprawidłową kontrolę dostępu.

web2py 3.2.2-stable (commit a7330a2bf21219fa77860b6665de927dd4f98e6d) jest podatny na Directory Traversal w funkcjach read_file()/write_file() (applications/admin/controllers/webservices.py).

Envoy przed wersjami 1.36.10, 1.37.6, 1.38.4 i 1.39.1 ma podatność w ścieżkach Utility::copyInternetAddressAndPort oraz QUIC client-address, które rekonstruują adresy IPv6 ze scopem. Ciąg zawiera identyfikator zakresu (percent scope), którego inet_pton nie może sparsować, co powoduje wyjątek lub przerwanie działania. Wdrożenia transparent-proxy z ORIGINAL_DST oraz dotknięte ścieżki QUIC mogą zakończyć proces. Problem naprawiono w wersjach 1.36.10, 1.37.6, 1.38.4 i 1.39.1.

Supabase Realtime przed wersją 2.111.2 ma podatność w autoryzacji, która nie honoruje poprawnie polityki bezpieczeństwa na poziomie wierszy (RLS) presence.read dla rozszerzenia, gdy klient kanału prywatnego ma przyznane presence.write, ale jawnie odmówione presence.read. W takiej sytuacji klient może otrzymywać wiadomości presence_diff zawierające metadane obecności innych członków, w tym lokalizację, status online, listę, oglądanie lub informacje o pisaniu. Wdrożenia z jednolitą widocznością obecności nie mają tej różnicy, a dane postgres_changes nie są dotknięte. Problem naprawiono w wersji 2.111.2.