Katalog podatności CVE

openssl_encrypt przed wersją 1.4.9 nie uwierzytelnia obecności slotów odzyskiwania w plikach szyfrowanych w formacie envelope, co pozwala atakującym na usunięcie slotów odzyskiwania bez ponownego szyfrowania ładunku. Atakujący mogą zmodyfikować nagłówek pliku, aby usunąć pola slotów odzyskiwania i ominąć uwierzytelnianie, cicho usuwając ścieżki odzyskiwania, które właściciel celowo dodał.

OpenRemote przed wersją 1.28.0 zawiera podatność na ujawnienie informacji między domenami w API REST powiadomień. Administratorzy dzierżawy mogą odczytać wysłane powiadomienia wszystkich dzierżaw, w tym treści wiadomości, wysyłając żądanie GET bez parametrów do punktu końcowego powiadomień.

AVideo przed wersją 24.0 zawiera podatność na fałszowanie żądań po stronie serwera (SSRF) w funkcji isSSRFSafeURL, która nie wyodrębnia osadzonych adresów IPv4 z formatów przejściowych IPv6 (NAT64, 6to4, Teredo). Nieuwierzytelnieni atakujący mogą ominąć ochronę SSRF przez punkt końcowy LiveLinks, aby dotrzeć do wewnętrznych usług i punktów końcowych metadanych chmury.

Brama OpenFaaS rejestruje GET /system/telemetry w gateway/main.go i, gdy włączone jest basic_auth, opakowuje każdy administracyjny handler /system/* w auth.DecorateWithBasicAuth. TelemetryHandler został pominięty w tym bloku od wersji 0.27.11, która wprowadziła trasę, do 0.27.14, która go dodała. Na dotkniętej bramie trasa dociera do proxy przekazującego bez sprawdzenia poświadczeń i zwraca to, co skonfigurowany dostawca serwuje dla /system/telemetry, więc każdy klient, który może dotrzeć do portu bramy, może odczytać telemetrię dostawcy niezależnie od ustawienia basic_auth. Ujawniona treść zależy od dostawcy i obejmuje metryki zasobów i wywołań dla faasd oraz stan podów lub klastra dla faas-netes.

Baserow wysyła źródło danych Application Builder bez sprawdzania wyniku kontroli uprawnień. Widoki dispatch i record-name są zadeklarowane z klasą uprawnień, która dopuszcza każdego wywołującego, a kontrola uprawnień nie powoduje przerwania wykonania. Nieuwierzytelnione żądanie może otrzymać wiersze i pola ze źródła danych, a identyfikatory są małymi liczbami całkowitymi, które można enumerować. Wersja 2.3.1 przekazuje raise_exception do tego samego wywołania.

Serwer Dash MCP był związany z adresem loopback, ale nigdy nie sprawdzał nazwy hosta, którą podało żądanie. src/mcp_server_dash.py skonstruował serwer dla trybu sieciowego z interfejsem ograniczonym do loopback i bez ustawień bezpieczeństwa transportu, więc nazwa, która została wskazana na adres loopback, nadal docierała do nasłuchującego, niosąc nazwę hosta atakującego. Strona w przeglądarce odwiedzającego mogła zatem sterować lokalnym serwerem i wywoływać jego narzędzia wyszukiwania firm i szczegółów plików przy użyciu poświadczeń Dropbox, które posiada serwer. Tylko tryb sieciowy był osiągalny w ten sposób; tryb standardowego wejścia nie. Poprawka dostarcza ustawienia bezpieczeństwa transportu, które umożliwiają sprawdzanie hosta i zezwalają tylko na nazwę i port loopback, odrzucając inne hosty przed uruchomieniem narzędzia. Repozytorium nie publikuje wersji, więc dotknięty zakres to commit poprzedzający poprawkę.

Polecenie configure akceptowało dowolny adres URL punktu końcowego i przechowywało go obok tokena dostępu użytkownika. ConfigureCommand.execute w src/cli.ts zapisywał wartość podaną dla opcji endpoint do profilu użytkownika bez przepuszczania jej przez createSafeUrl w src/config.ts, czyli pomocnika, który już ograniczał formę zmiennej środowiskowej tego samego ustawienia do hostów dostawcy przez HTTPS. Ponieważ ścieżka connect w src/mcp.ts dołącza przechowywany token jako poświadczenie Bearer do każdego żądania do skonfigurowanego punktu końcowego, użytkownik, który został przekonany do uruchomienia configure z punktem końcowym wybranym przez atakującego, wysyłał swój osobisty token dostępu do tego miejsca przy każdym kolejnym wywołaniu. Wersja 0.2.5 stosuje ten sam pomocnik do opcji.

tiger-gh-mcp-server uruchamiał swój transport MCP HTTP bez włączenia listy dozwolonych hostów, którą zapewnia bazowy SDK. src/httpServer.ts wywoływał wspólny pomocnik httpServerFactory i nigdy nie ustawiał opcji ochrony przed ponownym wiązaniem DNS, więc transport akceptował żądanie niezależnie od nazwy hosta, co czyniło lokalnie dostępny punkt końcowy GitHub MCP sterowalnym ze strony w przeglądarce odwiedzającego, która wskazywała nazwę kontrolowaną przez atakującego na związany adres. Poprawka przekazuje opcję jawnie wraz z aktualizacją zależności; sama aktualizacja nie zamknęłaby luki. Repozytorium nie opublikowało żadnego wydania obejmującego poprawkę, więc dotknięta granica to commit poprzedzający ją.

tiger-slack uruchomił swój transport HTTP MCP bez włączenia listy dozwolonych hostów dostarczanej przez bazowe SDK. Plik mcp/src/httpServer.ts wywoływał wspólny pomocnik httpServerFactory i nigdy nie ustawiał opcji ochrony przed ponownym wiązaniem DNS, więc transport akceptował żądania niezależnie od nazwy hosta. Strona w przeglądarce mogła wskazać kontrolowaną nazwę na adres, do którego serwer był przypisany, i sterować lokalnie dostępnym serwerem MCP Slack przez przeglądarkę odwiedzającego. Poprawka przekazuje opcję jawnie wraz z aktualizacją zależności; sama aktualizacja nie zamknęłaby luki.

Serwer MCP Telnyx udostępniał transport HTTP na wszystkich interfejsach i nie wymagał poświadczeń od wywołującego. Serwer obsługiwał MCP na ścieżce głównej, nasłuchując na wszystkich interfejsach, a parsowanie nagłówków uwierzytelniających nie kończyło się błędem, gdy były nieobecne, więc żądanie bez poświadczeń mogło zainicjować i wysyłać narzędzia. Wysyłka przekazywała własne poświadczenia serwera (klucz API Telnyx, sekret klienta i klucz wykonania kodu) do punktu końcowego, więc nieuwierzytelniony wywołujący mógł nimi działać. Obecny kod domyślnie ustawia host na loopback, wymaga klucza API serwera i egzekwuje go w middleware.

Narzędzie execute_ruby jest udokumentowane jako sandbox Ruby tylko do odczytu, ale jego lista blokad nie obejmuje punktów wejścia spawn w bibliotece pseudo-terminala. Normalne wywołanie narzędzia może uruchomić powłokę i wykonać komendy jako konto serwera. Wersja 1.6.1 ogranicza dozwolone require i blokuje dynamiczne wywołania, a 2.0.0 usuwa narzędzie.

ToolUniverse uruchamiał kod Pythona dostarczony przez wywołującego w piaskownicy, którą można było ominąć, na serwerze niewymagającym uwierzytelniania. Wykonawca narzędzia python_code_executor sprawdzał źródło pod kątem listy zabronionych nazw atrybutów i wywołań, ale pozostawiał dostępne wbudowane funkcje wyszukiwania atrybutów i nie blokował atrybutów dunder osiąganych przez wyszukiwanie stringów lub przez dozwolony moduł. Pozwalało to na przejście od klasy literału do jej baz i wyliczenie podklas w celu uzyskania odniesienia do modułów process i subprocess. Dodatkowy argument pozwalał na rozszerzenie listy dozwolonych importów przed inspekcją. Serwery HTTP i MCP nasłuchiwały na wszystkich interfejsach z włączonym debugowaniem i bez uwierzytelniania, więc każdy wywołujący mógł wykonać kod jako proces serwera. Wersja 1.3.0 dodaje uwierzytelnianie bearer-token, domyślnie ustawia adres na loopback i wzmacnia sprawdzanie atrybutów.

pg-aiguide uruchomił swój transport HTTP MCP bez włączenia listy dozwolonych hostów dostarczanej przez bazowe SDK. Plik src/httpServer.ts wywoływał wspólny pomocnik httpServerFactory i nigdy nie ustawiał opcji ochrony przed ponownym wiązaniem DNS, więc transport akceptował żądania niezależnie od nazwy hosta. Strona w przeglądarce mogła wskazać kontrolowaną nazwę na adres serwera i sterować lokalnie dostępnym serwerem MCP przez przeglądarkę odwiedzającego. Ochrona była już dostępna w pakowanym transporcie i po prostu nie została włączona, więc sama aktualizacja zależności nie zamknęłaby luki. Wersja 0.5.1 przekazuje opcję jawnie.

Narzędzie CLI mcp-router domyślnie uruchamiało serwer agregatora MCP na wszystkich interfejsach sieciowych i wymagało uwierzytelnienia tylko wtedy, gdy operator o to poprosił. Domyślne wywołanie polecenia serve wystawiało agregator i wszystkie serwery MCP na dostęp dla każdego, kto mógł dosięgnąć portu. Wersja 0.6.3 domyślnie używa adresu loopback i odmawia startu bez tokena, gdy host nie jest adresem loopback.

Narzędzie get-html-skeleton pobierało URL podany przez wywołującego po sprawdzeniu tylko składni. Walidacja nie sprawdzała nazwy hosta ani adresu, na który wskazuje, więc adresy loopback, link-local i prywatne były dozwolone, w tym adresy metadanych instancji chmury. Każdy wywołujący serwer MCP mógł odczytać wynik żądania do wewnętrznego punktu końcowego. Wersja 0.9.12 usuwa narzędzie.

mcp-go akceptował żądania na swoich transportach HTTP bez sprawdzania nagłówka Host. StreamableHTTPServer.ServeHTTP w server/streamable_http.go i SSEServer.ServeHTTP w server/sse.go obsługiwały każde żądanie przychodzące przez połączenie loopback niezależnie od nazwy hosta, a domyślna konfiguracja cross-origin w transporcie SSE zezwalała na dowolne pochodzenie. Strona w przeglądarce mogła wskazać kontrolowaną nazwę na adres loopback i dotrzeć do nasłuchującego serwera, wywołując narzędzia i odczytując zasoby, które serwer udostępniał przy założeniu, że tylko lokalne oprogramowanie może się połączyć. Żadna wersja przed 0.56.0 nie walidowała nagłówka na żadnym z transportów; 0.56.0 dodaje server/http_localhost.go, który odrzuca żądanie związane z loopbackiem z hostem niebędącym nazwą loopback i podłącza go do obu transportów.

Middleware proxy w inspectorze mcp-use przekazuje żądania do miejsca docelowego wskazanego przez wywołującego, bez sprawdzania hosta. Adresy loopback, link-local i prywatne były akceptowane, a walidacja nie była ponownie stosowana do przekierowań. Wywołujący mógł sprawić, że serwer wyśle żądania do adresów dostępnych tylko z hosta i odczytać odpowiedzi. Obecny kod sprawdza adresy przed proxy i ogranicza liczbę przekierowań.

W gemie resolv przed wersją 0.7.2 dla Ruby, podczas dekodowania odpowiedzi DNS, dla każdego nieznanego rekordu (typ, klasa) lub SvcParamKey generowana jest nowa klasa, która jest trwale rejestrowana jako stała i w hashach, co powoduje nieograniczony wzrost pamięci. Atakujący kontrolujący odpowiedzi DNS może wysłać odpowiedź z tysiącami nieznanych typów, powodując trwały wzrost pamięci procesu, który nie jest odzyskiwany przez GC.

FrontAccounting do wersji 2.4.20 przechowuje i weryfikuje hasła użytkowników jako niesolone skróty MD5. admin/users.php przekazuje md5($_POST['password']) do add_user() i update_user_password(), admin/change_current_user_password.php robi to samo, gdy użytkownik zmienia własne hasło, ścieżka zapomnianego hasła w includes/current_user.inc haszuje nowo wygenerowane hasło w ten sam sposób, a uwierzytelnianie wywołuje get_user_auth($loginname, md5($password)). Kod nie stosuje soli per hasło i nie zawiera wywołań password_hash(), password_verify() ani żadnego innego adaptacyjnego haszowania, więc identyczne hasła dają identyczne skróty, a atakujący, który uzyska tabelę użytkowników, może odzyskać hasła w postaci jawnej za pomocą prekomputerowanych tablic lub szybkiego łamania na GPU.

FrontAccounting do wersji 2.4.20 generuje token CSRF w end_form() w includes/ui/ui_controls.inc i osadza go jako ukryte pole _token w każdym formularzu, ale tylko admin/users.php i admin/change_current_user_password.php wywołują check_csrf_token() w celu jego walidacji. Żaden moduł obsługi transakcji finansowych nie waliduje tokenu, w tym gl/gl_journal.php, gl/gl_bank.php, purchasing/supplier_invoice.php, sales/customer_invoice.php, sales/customer_payments.php i admin/company_preferences.php, więc te punkty końcowe działają na danych POST bez sprawdzania pochodzenia. Atakujący, który sprawi, że uwierzytelniony użytkownik załaduje stronę pod kontrolą atakującego, może automatycznie wysłać formularz z innego pochodzenia do dowolnego z nich i spowodować zapisanie sfałszowanego wpisu księgowego, faktury, płatności klienta, transakcji bankowej lub zmiany konfiguracji firmy w sesji ofiary.