Katalog podatności CVE

W openssl_encrypt (pakiet pip openssl-encrypt) w wersjach <= 1.4.8, graficzny interfejs użytkownika przekazuje hasło do steganografii do procesu potomnego CLI w linii poleceń przez argument --stego-password (zarówno przy szyfrowaniu, jak i deszyfrowaniu) zamiast przez zmienną środowiskową, jak to ma miejsce dla głównego hasła. Każdy lokalny użytkownik może odczytać hasło steganograficzne z /proc/<pid>/cmdline przez cały czas życia podprocesu. Poprawiono w wersji 1.4.9.

openssl_encrypt przed wersją 1.4.9 zawiera podatność na niebezpieczne uprawnienia plików w graficznym interfejsie użytkownika, który zapisuje odszyfrowany tekst jawny z domyślnymi uprawnieniami odczytywalnymi dla wszystkich. Atakujący mogą odczytać odszyfrowane pliki wyjściowe utworzone przez GUI jako nieuprzywilejowani lokalni użytkownicy w systemach wieloużytkownikowych.

openssl_encrypt (pakiet pip openssl-encrypt) w wersjach <= 1.4.8 reklamuje przenośny obszar roboczy USB jako 'Zaszyfrowany obszar roboczy USB' z szyfrowaniem AES-256-GCM i zapisuje znacznik deklarujący, że obszar jest zaszyfrowany, ale katalog obszaru roboczego jest faktycznie przechowywany w postaci jawnej, a pochodny klucz szyfrujący nigdy nie jest do niego stosowany. Użytkownik, który ufa brandingowi i umieszcza pliki w obszarze roboczym, pozostawia je niezaszyfrowane na nośniku wymiennym, więc atakujący z fizycznym dostępem do nośnika może odczytać poufne pliki. Poprawiono w wersji 1.4.9, która zamyka obszar roboczy w uwierzytelnionym sejfie AES-256-GCM.

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ł.

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.

Darknet ma podatność polegającą na braku sprawdzenia indeksu tablicy warstw przed użyciem go do odczytu i zapisu poza przydzieloną pamięcią. Indeks pochodzi z pliku konfiguracyjnego, a parsowanie spreparowanego pliku wystarcza do wywołania awarii i zapisu poza pamięcią.

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.

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.

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.

W bibliotece resolv dla Ruby przed wersją 0.7.2 odkryto podatność w enkoderze DNS. Długość etykiety DNS jest zapisywana w jednym bajcie bez sprawdzania zakresu, co pozwala na zapisanie wartości z zakresu 0-255, w tym zarezerwowanych dla wskaźników kompresji. Atakujący może kontrolować nazwę hosta, co prowadzi do rozbieżności między nazwą zakodowaną a nazwą na wire, umożliwiając obejście list dozwolonych i kontroli egress.

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.

Podatność w Fonoster do wersji 0.22.7 pozwala uwierzytelnionemu użytkownikowi na zmianę nazwy dowolnego workspace'u. Obsługa updateWorkspace nie przerywa wykonania po zgłoszeniu braku członkostwa, a kontrola dostępu nie obejmuje tej operacji.

Podatność w APITable do wersji 1.13.0-beta.1 pozwala nieuwierzytelnionemu atakującemu na tworzenie powiadomień w systemie. Brak wymaganego logowania dla create handlera InternalNotifyController oraz proxy nginx umożliwiają dostęp do API.

Refleksyjne XSS w Netron w wersjach do 9.1.2 w aplikacji desktopowej przez niezdezynfekowane nazwy węzłów. Atakujący może ukrywać węzły, skanować porty lub wykorzystać podatność Chrome do zdalnego wykonania kodu.

Refleksyjne XSS w Netron w wersjach do 9.1.2 w aplikacji desktopowej przez niezdezynfekowane nazwy węzłów. Atakujący może ukrywać węzły, skanować porty lub wykorzystać podatność Chrome do zdalnego wykonania kodu.

Refleksyjne XSS w Netron w wersjach do 9.1.2 w aplikacji desktopowej przez niezdezynfekowane nazwy węzłów. Atakujący może ukrywać węzły, skanować porty lub wykorzystać podatność Chrome do zdalnego wykonania kodu.

Podatność w Eclipse SW360 w wersjach 19.0.0, 19.1.0, 19.2.0, 20.0.0, 20.1.0 pozwala atakującemu na manipulację nazwą pliku podczas przesyłania, co umożliwia dowolną ścieżkę traversal, gdy system używa przechowywania plików na dysku.