Katalog podatności CVE

Renovate przed wersją 44.79.0 zawiera podatność server-side request forgery pozwalającą użytkownikom wymusić na współdzielonym kliencie HTTP żądania do dowolnych wewnętrznych adresów URL poprzez presety extends lub customDatasources. Atakujący może wskazać preset na endpoint usługi metadanych instancji, aby uzyskać poświadczenia AWS lub wyciec dane wrażliwe przez logi Renovate.

Renovate przed wersją 44.60.1 zawiera podatność obejścia listy dozwolonych pozwalającą repozytoriom ustawiać zastrzeżone zmienne środowiskowe poprzez umieszczenie env w współdzielonym presecie. Atakujący kontrolujący zewnętrznie pochodzący preset może nadpisać zmienne takie jak PATH, LD_PRELOAD, NODE_OPTIONS lub GIT_SSL_CAINFO w procesach potomnych na instancjach self-hosted.

Renovate przed wersją 44.60.1 zawiera podatność obejścia listy dozwolonych pozwalającą użytkownikom repozytoriów ominąć ograniczenie allowedHeaders poprzez umieszczenie nagłówków hostRules w współdzielonych presetach. Atakujący może dostarczyć wewnętrzne lub zewnętrzne presety z niezwalidowanymi hostRules[].headers, aby wstrzyknąć własne nagłówki HTTP do żądań wysyłanych przez Renovate do innych hostów.

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.

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.

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 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ść 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.

n8n w wersjach przed 1.123.83 zawiera podatność obejścia autoryzacji, która pozwala edytorom współdzielonych workflow używać poświadczeń, do których nie mają dostępu, osadzając je w zagnieżdżonych lub inline sub-workflow narzędzi. Atakujący mogą zapisywać workflow z definicjami inline Workflow Tool lub Workflow Retriever odwołującymi się do zastrzeżonych poświadczeń, które wykonują się z wartościami poświadczeń właściciela workflow.

n8n w wersjach przed 2.41.4 oraz 2.42.x przed 2.42.1 zawiera podatność na niekontrolowane zużycie zasobów w nieuwierzytelnionym punkcie końcowym OAuth authorize. Klienty są rozwiązywane po ścieżce URL, ale surowy identyfikator wywołującego jest zapisywany jako klucz rekordu, co pozwala nieuwierzytelnionemu atakującemu tworzyć nieograniczoną liczbę rekordów klientów pierwszej strony, omijając limit rejestracji.

n8n w wersjach przed 2.41.4 oraz 2.42.x przed 2.42.1 zawiera podatność na zanieczyszczenie prototypu w narzędziu walidacji przepływów MCP, którego interpreter wykonuje kod dostarczony przez wywołującego w procesie głównym, odczytuje odziedziczone właściwości i pozwala na przypisanie do współdzielonych prototypów. Uwierzytelniony członek z uprawnieniem workflow:read może zastąpić wbudowaną metodę zwracającą wartość prawdziwą, aby obejść sprawdzanie uprawnień po stronie serwera i przejąć konta właścicieli bez MFA.

n8n w wersjach przed 2.41.4 oraz 2.42.x przed 2.42.1 zawiera podatność na wstrzyknięcie SQL w wersji 1 węzła Microsoft SQL, który podstawia wartości wyrażeń pola Query bezpośrednio do tekstu SQL bez parametryzacji. Gdy przepływ wiąże niezaufane dane wejściowe, takie jak pola webhooka, z polem Query, nieuwierzytelnieni zewnętrzni wywołujący mogą wykonać dowolny SQL na podłączonej bazie danych z uprawnieniami zapisanych poświadczeń.