Katalog podatności CVE

rclone przed wersją 1.75.0 montuje handler debugowania pprof jako własną trasę routera, omijając regułę uwierzytelniania fail-closed w głównym handlerze. Atakujący mogą uzyskać dostęp do punktu końcowego /debug/pprof/cmdline bez uwierzytelnienia, aby pobrać pełne argumenty procesu, w tym poświadczenia backendu.

rclone w wersjach od v1.72.0 do v1.74.4 (poprawione w v1.75.0) zawiera wiele podatności na odmowę usługi w parserze SquashFS backendu archiwum, który opiera się na zależności github.com/diskfs/go-diskfs. Parser nie sprawdza poprawności wartości superbloku i metadanych kontrolowanych przez atakującego przed ich użyciem. Atakujący, który może umieścić lub zmodyfikować obraz SquashFS w magazynie wystawionym przez zdalny :archive:, może stworzyć złośliwy obraz wywołujący panikę z powodu dzielenia przez zero (zerowy rozmiar bloku), panikę z powodu odczytu poza zakresem (przesunięcie metadanych inode poza zakres) lub pętlę CPU bez postępu (obcięty strumień metadanych). Warianty 1 i 2 kończą proces rclone i przez 'rclone serve sftp' mogą zawiesić cały serwer SFTP; wariant 3 powoduje ciągłe zużycie CPU. Parsowanie jest leniwe, więc ofiara lub zdalny klient musi odnieść się do złośliwego obiektu archiwum lub zejść do niego, aby go wyzwolić.

Winter CMS w wersjach przed 1.2.13 zawiera niekompletną poprawkę dla podatności ucieczki z sandboxa Twig w System\Twig\SecurityPolicy, która pozwala uwierzytelnionym użytkownikom backendu z uprawnieniami do edycji szablonów na ominięcie ograniczeń sandboxa. Atakujący mogą wykorzystać przekazywanie metod przez modele Eloquent i konstruktory zapytań, używając metod takich jak saveQuietly(), deleteQuietly(), increment(), decrement() i newQuery(), aby odczytywać i modyfikować dowolne rekordy bazy danych, wykonywać dowolne SQL i osiągnąć zdalne wykonanie kodu poprzez wstrzyknięcie PHP do sekcji kodu szablonu.

Winter CMS przed wersją 1.2.13 zawiera podatność na lokalne dołączanie plików w filtrze JavascriptImporter, która pozwala uwierzytelnionym użytkownikom z uprawnieniem cms.manage_assets na ujawnienie dowolnych plików czytelnych dla serwera poprzez umieszczenie dyrektyw =include lub =require w motywowych zasobach JavaScript. Atakujący mogą odwoływać się do plików takich jak .env poza katalogiem motywu, a połączone dane wyjściowe serwowane przez trasę combine stają się czytelne dla nieuwierzytelnionych odwiedzających, ujawniając klucze aplikacji i poświadczenia bazy danych.

Nokogiri przed wersją 1.19.1 nie sprawdza wartości zwracanej przez xmlC14NExecute w metodzie canonicalize, zwracając pusty ciąg w przypadku błędu zamiast zgłosić wyjątek. Atakujący mogą to wykorzystać do obejścia walidacji podpisu w bibliotekach SAML niższego poziomu, dostarczając nieprawidłowy zkanonizowany XML, który jest błędnie akceptowany jako prawidłowy.

Nokogiri przed wersją 1.19.3 zawiera wyciek pamięci w metodzie transform stylu XSLT podczas przetwarzania ciągów Ruby zawierających bajty zerowe. Atakujący mogą to wykorzystać, przekazując kontrolowane dane wejściowe z bajtami zerowymi do parametrów transform, powodując wyciek alokacji sterty i umożliwiając odmowę usługi dla długo działających procesów.

Nokogiri w wersjach przed 1.19.3 zawiera podatności na odmowę usługi przez wyrażenia regularne w tokenizatorze selektorów CSS, dotyczące tokenizacji literałów łańcuchowych i identyfikatorów. Atakujący mogą wstrzyknąć złośliwe selektory CSS do metod takich jak Node#css, Node#at_css i Searchable#search, powodując wykładnicze cofanie się wyrażeń regularnych i odmowę usługi.

Nokogiri przed wersją 1.19.4 zawiera możliwy nieprawidłowy odczyt pamięci (poza zakresem) w chronionej metodzie wewnętrznej Node#initialize_copy_with_args, używanej przez Node#dup i #clone, która rozpakowywała swój argument źródłowy jako xmlNode bez sprawdzenia typu. Jeśli kod aplikacji wywoła tę chronioną metodę z argumentem niebędącym Node (np. Namespace), odczytuje xmlNs poza zakresem, powodując awarię procesu. Jest to wyzwalane tylko przez błąd programistyczny i nie może być wyzwolone przez niezaufane dane wejściowe ani normalne użycie publicznego API. Dotyczy tylko CRuby. Wersja 1.19.4 dodaje sprawdzenie typu i zgłasza TypeError.

NLTK przed wersją 3.10.3 zawiera podatność na przechodzenie poza katalog (path traversal) w czytnikach korpusów, które ponownie otwierają ścieżki pochodzące z katalogu głównego za pomocą wbudowanej funkcji open() zamiast nltk.pathsec.open(), co pozwala dowiązaniom symbolicznym na ucieczkę z zaufanych katalogów głównych. Atakujący, którzy umieszczą dowiązania symboliczne do plików korpusu w zaufanym katalogu danych, mogą ujawnić zawartość poza katalogiem głównym za pomocą normalnych metod czytnika korpusów, takich jak channels(), domains() i synonyms().

NLTK przed wersją 3.10.3 nie waliduje opcji JVM przekazywanych przez parametr options w funkcji java(), co pozwala atakującym na wstrzykiwanie niebezpiecznych flag JVM. Atakujący mogą dostarczyć złośliwe opcje, takie jak -agentpath, -javaagent lub @argfile, do klas opakowujących Stanford, aby osiągnąć wykonanie dowolnego kodu.

NLTK w wersjach przed 3.10.3 zawiera podatność polegającą na ominięciu sandboxa ścieżek w konstruktorach czytników korpusów, która pozwala atakującym na odczyt plików poza zamierzonym katalogiem danych. Atakujący mogą dostarczyć dowolne ścieżki korpusu do konstruktorów LinThesaurusCorpusReader i PanLexLiteCorpusReader, aby uzyskać dostęp do zawartości systemu plików i baz danych SQLite poza granicami sandboxa pathsec.

Słabość autoryzacji w obsłudze repozytoriów Composer w JFrog Artifactory może pozwolić uwierzytelnionemu użytkownikowi, w określonych warunkach, na odczyt metadanych pakietów z repozytoriów, do których nie ma uprawnień. Problem dotyczy poufności i został rozwiązany w poprawionych wersjach Artifactory.

W określonych okolicznościach użytkownik o niskich uprawnieniach może wysłać żądanie do zdalnych repozytoriów CocoaPods za pośrednictwem JFrog Artifactory External Dependency.

Nextcloud MCP Server przed wersją 0.117.2 ma endpoint POST /webhooks/nextcloud w pliku nextcloud_mcp_server/vector/webhook_receiver.py, który domyślnie nie wymaga uwierzytelnienia, ponieważ WEBHOOK_SECRET domyślnie ma wartość None, a walidacja przy starcie go nie wymaga. Gdy WEBHOOK_SECRET nie jest ustawiony, handle_nextcloud_webhook() akceptuje nieuwierzytelnione żądania. Pole payload["user"]["uid"] parsowane w nextcloud_mcp_server/vector/webhook_parser.py jest kontrolowane przez atakującego i jest używane bez krzyżowej weryfikacji sesji uwierzytelnionej dla operacji Qdrant, co pozwala atakującemu sieciowemu na usunięcie lub wyzwolenie ponownego indeksowania wektorów osadzeń dla dowolnego użytkownika oraz zniszczenie indeksu wyszukiwania semantycznego poprzez wysyłanie sfałszowanych zdarzeń usunięcia. Problem został naprawiony w wersji 0.117.2.

mcp-shell to serwer MCP do bezpiecznego, audytowalnego i na żądanie wykonywania poleceń powłoki. Przed wersją 0.6.0 domyślny plik security.yaml zezwala na /usr/bin/git, podczas gdy security.go pomija ! w containsShellMetacharacters i containsDangerousShellConstructs i nie stosuje żadnej polityki argumentów dla poszczególnych wykonywalnych plików. Osoba wywołująca narzędzie MCP shell_exec może podać argument polecenia /usr/bin/git -c alias.pwn=!<arbitrary-command>, powodując, że Git utworzy alias powłoki i wykona dowolne polecenia systemu operacyjnego jako użytkownik procesu mcp-shell. Domyślny obraz Dockera działa jako mcpuser z zainstalowanym Git i włączonym trybem bezpiecznym, więc obejście jest możliwe do wykorzystania w domyślnym wdrożeniu bez dodatkowego uwierzytelnienia poza łącznością MCP. Problem został naprawiony w wersji 0.6.0.

mcp-shell to serwer MCP do bezpiecznego, audytowalnego i na żądanie wykonywania poleceń powłoki. Przed wersją 0.6.0 domyślny plik security.yaml w Dockerze zawiera /bin/bash w allowed_executables, podczas gdy security.go waliduje tylko pierwszy token, a checkBlockedPatternsAndCommands nie odrzuca flagi trybu poleceń powłoki -c. Osoba wywołująca narzędzie MCP shell_exec może podać argument polecenia `/bin/bash -c <arbitrary-command>`, który przechodzi walidację i dociera do executor.go, gdzie parseCommand i exec.CommandContext wykonują dowolne polecenie jako mcpuser poza zamierzoną listą dozwolonych. Problem został naprawiony w wersji 0.6.0.

mcp-shell przed wersją 0.6.0 domyślnie wyłącza zabezpieczenia, a gdy zmienna MCP_SHELL_SEC_CONFIG_FILE nie jest ustawiona, uruchamia się bez polityki bezpieczeństwa. Walidator poleceń pomija wtedy kontrolę i pozwala na wykonanie dowolnych poleceń systemowych przez podłączony model LLM. Problem został naprawiony w wersji 0.6.0.

QWED-MCP przed wersją 0.2.1, funkcja verify_math_expression() w src/qwed_mcp/engines/math_engine.py przekazuje kontrolowane przez atakującego wyrażenie i ciąg claimed_result bezpośrednio do SymPy's parse_expr() po tylko normalizacji składni daszka do składni potęgowej Pythona, bez ograniczania global_dict, usuwania wbudowanych funkcji Pythona ani walidacji AST wyrażenia. Ponieważ parse_expr() wywołuje eval() Pythona z dostępnymi wbudowanymi funkcjami, atakujący, który może spowodować, że wywołujący downstream przekaże niezaufane dane do tej publicznej funkcji bibliotecznej, może użyć funkcji importu Pythona do wykonania dowolnych poleceń systemu operacyjnego jako użytkownik procesu qwed-mcp, odczytać lub modyfikować dostępne dane, eksfiltrować sekrety procesu lub dotrzeć do wewnętrznych usług. Domyślny rejestr narzędzi MCP nie udostępnia verify_math_expression(), więc wykorzystanie wymaga integracji downstream, która wywołuje API biblioteki z danymi kontrolowanymi przez atakującego. Problem został naprawiony w wersji 0.2.1.

PraisonAI przed wersją 4.6.51 udostępnia endpoint /api/v1/runs bez uwierzytelnienia. Każdy, kto ma dostęp do sieci, może przesyłać zadania, odczytywać wyniki, anulować uruchomienia lub usuwać zadania, używając poświadczeń operatora. Poprawka dodaje middleware PRAISONAI_JOBS_API_KEY.

PraisonAI przed wersją 4.6.58, funkcja _handle_connection() w Browser Server sprawdza pochodzenie rozszerzenia Chrome za pomocą re.match() i niezakotwiczonego wyrażenia chrome-extension://[a-z0-9]{32}. Dodatkowe znaki na końcu przechodzą przed websocket.accept(), co pozwala na komendy start_session i nieautoryzowaną automatyzację przeglądarki. Problem został naprawiony w wersji 4.6.58.