Katalog podatności CVE

Better Auth w wersjach od 1.5.0-beta.12 do 1.7.7 zawiera podatność obejścia uwierzytelniania w pluginie OAuth Proxy pozwalającą nieuwierzytelnionym atakującym zalogować się jako inni użytkownicy poprzez sfałszowanie zaszyfrowanych profili. Gdy proxy współdzieli globalny sekret, a stan przechowywany w cookie jest używany, atakujący może uzyskać zaszyfrowany stan dla fałszywego profilu ze zweryfikowanym adresem e-mail ofiary, aby przejąć konto poprzez niejawne powiązanie.

Better Auth @better-auth/sso w wersjach od 1.7.0-rc.2 do 1.7.3 zawiera podatność obejścia uwierzytelniania pozwalającą uwierzytelnionym użytkownikom zalogować się jako inni użytkownicy poprzez zarejestrowanie osobistego dostawcy SSO. Atakujący może skopiować issuer OIDC lub entity ID SAML legalnego dostawcy i podać subject lub NameID ofiary, ponieważ wyszukiwanie konta ignoruje providerId, tworząc sesje dla kont ofiar.

Better Auth od wersji 1.4.0-beta.18 przed 1.7.7 zawiera lukę obejścia uwierzytelniania, która pozwala nieuwierzytelnionym atakującym zalogować się jako inni użytkownicy poprzez ponowne użycie wartości stanu OAuth jako tokenów Magic Link. Atakujący może rozpocząć logowanie OAuth z adresem e-mail ofiary i przesłać zwrócony stan do weryfikacji Magic Link, uzyskując sesje lub tworząc fałszywie zweryfikowane konta e-mail.

W Better Auth (@better-auth/drizzle-adapter i better-auth od 1.6.17 przed 1.7.7 oraz @better-auth/kysely-adapter od 1.6.17 przed 1.7.0) występuje warunek wyścigu w ograniczaniu liczby żądań opartym na bazie danych PostgreSQL — sprawdzenie limitu nie jest atomowe względem aktualizacji licznika. Zdalni atakujący mogą wysyłać serie równoczesnych żądań, które wspólnie przechodzą sprawdzenie, przekraczając skonfigurowane limity dla logowania hasłem, weryfikacji dwuskładnikowej, kodów jednorazowych, resetu hasła i innych chronionych punktów końcowych.

GitPython od wersji 3.1.62 do 3.2.0 zawiera błąd podążania za dowiązaniami symbolicznymi w Submodule.move(), który sprawdza cel tylko leksykalnie i nie odrzuca dowiązań symbolicznych w pośrednich komponentach ścieżki. Niezaufane repozytorium może zatwierdzić dowiązanie symboliczne wskazujące poza drzewo robocze, przez co aplikacja przenosząca zainicjowany podmoduł pod nim przenosi checkout na zewnątrz i uszkadza indeks oraz .gitmodules.

GitPython przed wersją 3.2.0 zawiera podatność wstrzyknięcia argumentów w metodzie Head.checkout() pozwalającą zdalnym atakującym odczytać dowolne pliki poprzez podanie nazwy gałęzi interpretowanej jako opcja git. Atakujący może hostować repozytorium, którego domyślna gałąź nazywa się --pathspec-from-file=<path>, powodując wyciek zawartości plików przez komunikaty GitCommandError w aplikacjach klonujących i przełączających się na aktywną gałąź.

GitPython w wersjach od 3.1.30 do 3.2.0 zawiera podatność zdalnego wykonania kodu w metodzie Remote.pull(), której zabezpieczenie przed niebezpiecznymi opcjami sprawdza tylko argumenty nazwane, a nie pozycyjny refspec. Atakujący kontrolujący refspec może podać --upload-pack=<command>, aby wykonać polecenia systemowe jako proces wywołujący przez transport lokalny lub SSH.

GitPython w wersjach przed 3.2.0 zawiera podatność umożliwiającą zdalne wykonanie kodu, ponieważ Git.ls_remote przekazuje adresy URL bez walidacji check_unsafe_protocols. Atakujący mogą podać adresy URL typu ext:: remote-helper, aby wykonać polecenia, gdy git zezwala na transport ext; podobny problem dotyczy merge_base i IndexFile.move, które akceptują wstrzyknięcie opcji.

GitPython w wersjach przed 3.2.0 zawiera podatność typu regular expression denial of service we wzorcu _re_actor_epoch używanym przez parse_actor_and_date dla linii author, committer i tagger. Atakujący może udostępnić repozytorium z obiektami commit lub tag zawierającymi długie linie wypełnione spacjami bez prawidłowej epoki lub strefy czasowej, powodując kwadratowe cofanie i wyczerpanie CPU.

GitPython przed wersją 3.2.0 zawiera podatność ujawnienia informacji, która pozwala złośliwym repozytoriom na rozwijanie zmiennych środowiskowych przez separate_git_dir w Repo._clone(), gdzie pominięto expand_vars=False przy wywołaniu Git.polish_url(). Atakujący mogą utworzyć nazwę podmodułu w .gitmodules zawierającą składnię zmiennych, tak że clone i submodule_update ujawniają sekrety w nazwach katalogów .git/modules i logach DEBUG.

Parse Server w wersjach przed 8.6.97 oraz 9.0.0 przed 9.10.2-alpha.6 nie obsługuje błędów pojawiających się podczas wysyłania e-maili weryfikacyjnych lub resetowania hasła, co powoduje zakończenie procesu serwera. Klient posiadający jedynie publiczne klucze aplikacji może zarejestrować się, zażądać e-maila weryfikacyjnego lub resetu hasła, gdy dostawca poczty odrzuca wiadomość, ogranicza liczbę żądań lub jest niedostępny, doprowadzając do awarii serwera.

n8n w wersjach przed 1.123.83 zawiera podatność obejścia autoryzacji, która pozwala uwierzytelnionym członkom podszyć się pod tożsamość workflow, podając zaufany identyfikator w trybie inline JSON Execute Sub-workflow. Atakujący może ustawić ten identyfikator, aby uzyskać poświadczenia z projektów, do których nie należy, oraz modyfikować dane statyczne innego workflow i wysyłkę workflow błędów.

n8n przed wersją 1.123.83, 2.x przed 2.41.4 oraz 2.42.x przed 2.42.1 zawiera obejście uwierzytelniania, ponieważ dynamiczne rozwiązywanie ścieżek webhooków dopasowywało żądania tylko po ścieżce, ignorując identyfikator generowany przez serwer, który jest jedynym nieodgadywalnym składnikiem URL. Nieuwierzytelnieni atakujący mogą pominąć ten identyfikator w żądaniach do tras webhook, form lub MCP, aby wykonywać workflow w niepowiązanych projektach z użyciem ich poświadczeń.

n8n w wersjach przed 2.41.4 oraz 2.42.x przed 2.42.1 zawiera obejście autoryzacji w punkcie końcowym tworzenia Agentów. Endpoint przyjmuje identyfikator Agenta podany przez wywołującego, sprawdza uprawnienia tylko względem żądanego projektu i aktualizuje istniejącego Agenta bez weryfikacji, do którego projektu należy. Uwierzytelniony użytkownik z dostępem tylko do odczytu Agentów innego projektu może przenieść tego Agenta do swojego projektu i zmienić jego nazwę, schemat oraz wersję.

n8n w wersjach przed 2.41.4 oraz 2.42.0 przed 2.42.1 nie waliduje identyfikatorów poświadczeń przechowywanych w parametrach węzła agenta, gdy edytor zapisuje współdzielony workflow, ponieważ sprawdzenie obejmuje tylko pole credentials węzła. Edytor może skonfigurować węzeł Message an Agent w trybie inline z kontrolowanymi przez siebie narzędziami, aby uzyskać poświadczenia właściciela i wysłać odszyfrowane sekrety do wybranego przez atakującego miejsca.

n8n w wersjach przed 1.123.83, 2.41.4 i 2.42.1 zawiera podatność typu stored cross-site scripting w modalu podglądu plików, który ponownie publikuje dane binarne jako niesandboxowany blob URL w tej samej domenie. Członek, który prześle spreparowany element, może uruchomić skrypt w domenie n8n u każdego, kto go wyświetli — zazwyczaj właściciela — i działać w jego sesji.

n8n w wersjach przed 1.123.83, 2.x przed 2.41.4 oraz 2.42.x przed 2.42.1 zawiera podatność prototype pollution w kreatorze przepływów AI. Łączy połączenia przepływu używając nazw węzłów jako składowych obiektu bez sprawdzania kluczy zarezerwowanych. Uwierzytelnieni użytkownicy mogą tworzyć węzły o nazwie __proto__ przez API i wywołać operację connect-nodes, aby zanieczyścić prototyp obiektu globalnego, zakłócając działanie instancji do momentu restartu.

n8n w wersjach przed 1.123.83, 2.x przed 2.41.4 oraz 2.42.x przed 2.42.1 zawiera podatność typu stored cross-site scripting w hostowanej stronie czatu Chat Trigger, gdzie niedostatecznie oczyszczone wartości customCss są wstawiane do strony jako znaczniki. Autorzy workflow mogą opublikować czat bez uwierzytelnienia użytkownika n8n, którego ładunek wykonuje się w domenie instancji, działając na sesjach zalogowanych odwiedzających.

n8n w wersjach przed 2.41.4 oraz 2.42.x przed 2.42.1 zawiera obejście podpisu w punkcie końcowym waiting-webhook, który wybiera walidację Send-and-Wait przed normalizacją alternatywnej formy odwołania do węzła. Atakujący posiadający token wznowienia wykonania może zatwierdzić oczekujące wykonania przeznaczone dla innych, uruchamiając dalsze działania na poświadczeniach właściciela workflow, potencjalnie w tym wykonanie poleceń.

n8n w wersjach przed 1.123.83, 2.x przed 2.41.4 oraz 2.42.x przed 2.42.1 zawiera podatność umożliwiającą wykonanie kodu w operacji Log węzła Git, która nie usuwa lokalnej konfiguracji git repozytorium przed wywołaniem zewnętrznego programu. Uwierzytelnieni członkowie, którzy mogą wskazać węzeł — także jako narzędzie agenta — na repozytorium o kontrolowanej lokalnej konfiguracji, mogą wykonać programy jako użytkownik procesu n8n.