Katalog podatności CVE

@better-auth/stripe w wersjach >= 1.4.11 i < 1.6.21 oraz >= 1.7.0-beta.0 i < 1.7.0-beta.10 zawiera obejście autoryzacji w akcjach subskrypcji organizacji. Middleware waliduje identyfikator organizacji z parametru zapytania względem callbacku authorizeReference, ale handler odczytuje identyfikator organizacji tylko z ciała żądania i w razie braku używa aktywnej organizacji z sesji wywołującego. Gdy te wartości się różnią, uwierzytelniony członek wielu organizacji może wykonywać akcje subskrypcji (anulowanie, zmiana planu, przywrócenie, dostęp do portalu rozliczeniowego) wobec organizacji, do której należy, ale którą nie powinien zarządzać, oraz uzyskać dostęp do danych rozliczeniowych innej organizacji, w tym metod płatności, faktur i stanu subskrypcji.

@better-auth/sso przed wersją 1.6.21 zawiera wiele luk obejścia uwierzytelniania w obsłudze dostawców SSO, umożliwiających atakującym logowanie się jako dowolni użytkownicy. Atakujący mogą wykorzystać niezgodności w parsowaniu weryfikacji domeny, osierocone konta dostawców, niepowiązane asercje SAML lub odbite XSS na punktach końcowych wylogowania, aby uzyskać nieautoryzowany dostęp do sesji i przejąć konto.

better-auth w wersjach >= 1.1.3 i < 1.6.22 (oraz wersje pre-release >= 1.7.0-beta.0 i < 1.7.0-beta.10) jest podatny na przejęcie konta przez pre-account hijacking przy logowaniu przez magic-link lub email-OTP, gdy włączona jest rejestracja przez email/hasło. Atakujący rejestruje konto z adresem e-mail ofiary i wybranym przez siebie hasłem; konto pozostaje niezweryfikowane. Gdy prawowity właściciel później loguje się przez magic-link lub email-OTP, konto zostaje oznaczone jako zweryfikowane bez usunięcia istniejącego hasła lub unieważnienia istniejących sesji, więc hasło atakującego pozostaje ważne, zapewniając mu trwały dostęp do konta ofiary. Poprawione w wersjach 1.6.22 i 1.7.0-beta.10.

GitPython przed wersją 3.1.50 nie waliduje znaków nowej linii w parametrze section funkcji config_writer(), umożliwiając atakującym wstrzyknięcie dowolnych nagłówków sekcji do pliku .git/config. Atakujący mogą wstrzyknąć znaki nowej linii, aby utworzyć sfałszowaną sekcję [core] z hooksPath wskazującym na kontrolowane przez atakującego katalogi, co prowadzi do zdalnego wykonania kodu po uruchomieniu hooków gita.

GitPython przed wersją 3.1.51 zawiera niekompletną blokadę wstrzykiwania komend, która nie uwzględnia funkcji skracania długich opcji gita. Atakujący mogą ominąć zabezpieczenie przed niebezpiecznymi opcjami, używając skróconych nazw opcji, takich jak upload_p zamiast upload_pack, które git rozpoznaje jako niebezpieczne opcje i wykonuje dowolne komendy.

GitPython przed wersją 3.1.51 nie zabezpiecza przed niebezpiecznymi opcjami Git przekazywanymi jako argumenty słownikowe w metodach Repo.archive() i git.ls_remote(), co umożliwia wstrzyknięcie poleceń przez opcje takie jak --exec/--upload-pack. Dodatkowo, Repo.iter_commits() i Repo.blame() nie sprawdzają argumentów rewizji zaczynających się od myślnika, co pozwala na otwarcie i obcięcie dowolnego pliku poprzez rewizję --output=<path>. Wymagana jest aplikacja przekazująca kontrolowane przez atakującego argumenty do tych metod.

GitPython przed wersją 3.1.52 jest podatny na wyciek zmiennych środowiskowych w metodzie Repo.clone_from(). Adres URL zdalnego repozytorium jest przetwarzany przez Git.polish_url(), który na platformach innych niż Cygwin wywołuje os.path.expandvars() na URL-u przed wykonaniem git clone. Atakujący kontrolujący URL klonowania może osadzić tokeny $NAME lub ${NAME}, które są rozwijane do wartości zmiennych środowiskowych procesu (np. AWS_SECRET_ACCESS_KEY lub GITHUB_TOKEN). Powstały URL, zawierający teraz sekret, jest przesyłany przez sieć do hosta kontrolowanego przez atakującego podczas próby klonowania.

W bibliotece axios w wersjach 0.31.1 przed 0.33.0 oraz 1.15.1 przed 1.18.0 występuje niekompletne obejście ograniczenia głębokości w pliku toFormData.js. Atakujący kontrolujący klucze obiektów i zagnieżdżone wartości przekazywane do serializacji formularza lub parametrów może wywołać błąd RangeError z JSON.stringify, powodując odmowę usługi w ścieżce żądania.

axios w środowisku Node.js używające adaptera HTTP może kierować żądania przez proxy kontrolowane przez atakującego. axios zabezpiecza scaloną konfigurację żądania, tworząc obiekt z prototypem null, ale interceptory żądań działają po scaleniu; popularny wzorzec niezmiennego interceptora, taki jak {...config} lub Object.assign({}, config), konwertuje zabezpieczoną konfigurację z powrotem na zwykły obiekt. axios następnie wysyła ten obiekt bez ponownego zabezpieczania, a adapter HTTP Node odczytuje config.proxy przez łańcuch prototypów. Jeśli atakujący może zanieczyścić Object.prototype.proxy, dotknięte żądania mogą być kierowane przez proxy kontrolowane przez atakującego. W przypadku zwykłych żądań HTTP proxy może obserwować nagłówki Authorization, Basic auth z config.auth, metodę, bezwzględny URL, Host i treść żądania oraz może zwrócić własną odpowiedź. Dotyczy wersji >=0.31.1 (naprawione w 0.33.0) i >=1.15.2 (naprawione w 1.18.0).

Axios w wersjach 1.7.0 przed 1.18.0 nie egzekwuje limitu maxBodyLength dla ciał żądań typu WHATWG ReadableStream w adapterze fetch, gdy nie można określić Content-Length. Atakujący mogą dostarczyć dane strumieniowe o nieznanej długości, aby ominąć limity rozmiaru przesyłania i spowodować niekontrolowany egress sieciowy lub wyczerpanie zasobów.

Axios jest podatny na gadżety zanieczyszczenia prototypu po stronie odczytu, które mogą zmienić konstrukcję żądania, gdy Object.prototype został już zanieczyszczony przez oddzielną podatność lub zależność. W aliasach metod bez ciała (axios.get(), axios.delete(), axios.head(), axios.options()), dziedziczone dane są odczytywane przez (config || {}).data przed normalizacją konfiguracji, co powoduje wysłanie kontrolowanego przez atakującego ciała w żądaniach, które go nie ustawiły. Dodatkowe ścieżki niskiego poziomu, osiągalne tylko przy bezpośrednim wywoływaniu eksportowanych adapterów/pomocników (np. lib/adapters/http.js, unsafe/helpers/resolveConfig.js) z czystymi konfiguracjami i bez własnego proxy lub paramsSerializer, mogą dziedziczyć zanieczyszczone wartości proxy (kierowanie żądań przez proxy kontrolowane przez atakującego) lub wartości paramsSerializer (kontrolowana przez atakującego serializacja URL). Te gadżety niskiego poziomu nie reprodukują się przez normalne wywołania axios wysokiego poziomu w wersji 1.15.2+. Problem jest naprawiony w axios 1.18.0 i 0.33.0.

W bibliotece axios w wersjach 0.31.0 przed 0.33.0 oraz 1.15.0 przed 1.18.0 adres 0.0.0.0 nie jest rozpoznawany jako adres pętli zwrotnej w pliku shouldBypassProxy.js. Atakujący może użyć adresu URL 0.0.0.0, aby kierować żądania przez skonfigurowane proxy, potencjalnie ujawniając lokalne usługi, gdy proxy może osiągnąć cel.

Biblioteka axios w wersjach 0.28.0 i nowszych zawiera niekontrolowaną rekurencję w funkcji formDataToJSON podczas przetwarzania nazw pól FormData z głęboko zagnieżdżonymi segmentami w nawiasach. Atakujący może dostarczyć FormData z nazwami pól zawierającymi tysiące zagnieżdżonych nawiasów, co prowadzi do wyczerpania stosu JavaScript i błędu RangeError, powodując awarię żądania lub zakończenie procesu w aplikacjach bez obsługi wyjątków.

Biblioteka axios w wersjach od 0.28.0 do 0.32.9 oraz od 1.0.0 do 1.17.9 zawiera niekontrolowaną rekurencję w funkcji formDataToJSON (udostępnianej jako axios.formToJSON() i używanej wewnętrznie przy serializacji FormData z Content-Type: application/json). Przekazanie kontrolowanych przez atakującego nazw pól FormData z tysiącami segmentów w nawiasach powoduje nieograniczoną rekurencję w buildPath(), wyczerpując stos JavaScript i powodując błąd RangeError, co prowadzi do odmowy usługi.

Traefik w wersjach >= v3.7.0 i <= v3.7.7 zawiera podatność na path traversal w oprogramowaniu pośredniczącym RewriteTarget dostawcy Kubernetes Ingress NGINX (generowanym z adnotacji nginx.ingress.kubernetes.io/rewrite-target). Gdy ścieżka Ingress używa wyrażenia regularnego przechwytującego tekst kontrolowany przez atakującego bez wymagania separatora ścieżki (np. ścieżka /api(.*) z celem przepisania /$1), spreparowane żądanie, takie jak /api../admin, pasuje do publicznego routera, jest przepisywane na ścieżkę z przejściem kropkowym (/../admin) i przekazywane bez walidacji normalizacji po zastąpieniu. Backend, który normalizuje segmenty kropkowe, rozwiązuje ścieżkę do chronionego punktu końcowego (np. /admin) osiągalnego tylko przez oddzielny router zabezpieczony BasicAuth, DigestAuth lub ForwardAuth, co skutkuje obejściem uwierzytelniania na poziomie trasy. Problem został naprawiony w wersji v3.7.8.

Klient FreeRDP dla systemu Windows przed wersją 3.29.0 zawiera podatność na przepełnienie bufora sterty w wirtualnym kanale schowka podczas przetwarzania PDU CLIPRDR_FILE_CONTENTS_RESPONSE bez walidacji rozmiaru dostarczonego przez serwer względem bufora docelowego. Złośliwy serwer RDP może wysłać odpowiedź z ładunkiem danych znacznie większym niż żądany, powodując dowolne uszkodzenie pamięci sterty, co może umożliwić zdalne wykonanie kodu, gdy użytkownik wykona operację wklejania.

FreeRDP przed wersją 3.29.0 zawiera podatność na dereferencję pustego wskaźnika podczas czyszczenia żądania sterowania urządzeniem smartcard, gdy dekodowanie stanu czytnika nie powiedzie się. Atakujący mogą wysyłać zniekształcone żądania IRP smartcard z niezerowym cReaders i obciętymi danymi stanu czytnika, aby spowodować awarię procesu poprzez dostęp do pustego wskaźnika w funkcjach free_reader_states.

FreeRDP przed wersją 3.29.0 zawiera podatności na odczyt poza zakresem w asynchronicznym proxy komunikatów aktualizacji dla podstawowych poleceń rysowania PolygonSC i PolygonCB. Gdy AsyncUpdate jest włączone (np. xfreerdp /async-update), funkcje update_message_PolygonSC() i update_message_PolygonCB() alokują nową tablicę punktów, ale kopiują dane punktów z adresu struktury order zamiast z polygonSC->points / polygonCB->points, co skutkuje odczytem poza zakresem po stronie klienta. Złośliwy lub skompromitowany serwer RDP wysyłający spreparowane polecenia aktualizacji PolygonSC/PolygonCB może wywołać ujawnienie pamięci lub awarię klienta.

FreeRDP przed wersją 3.29.0 zawiera podatności na use-after-free w stercie po stronie klienta w asynchronicznym proxy komunikatów aktualizacji dla RAIL WINDOW_STATE_ORDER i NOTIFY_ICON_STATE_ORDER, gdy AsyncUpdate jest włączone. Gdy złośliwy lub skompromitowany serwer RDP wysyła spreparowane polecenia aktualizacji, proxy komunikatów płytko kopiuje struktury zawierające zagnieżdżone wskaźniki należące do parsera (np. titleInfo.string, windowRects, visibilityRects, bufory ikon). Parser zwalnia te zagnieżdżone bufory po zakończeniu wywołania zwrotnego, więc zakolejkowana asynchroniczna wiadomość później wysyła nieaktualne wskaźniki, potencjalnie powodując uszkodzenie pamięci lub awarię klienta.

FreeRDP przed wersją 3.29.0 zawiera podatność na use-after-free w stercie po stronie klienta w asynchronicznym proxy komunikatów aktualizacji dla WINDOW_ICON_ORDER, gdy AsyncUpdate jest włączone (np. xfreerdp /async-update). W funkcji update_message_WindowIcon() płytkie CopyMemory() nadpisuje świeżo zaalokowane lParam->iconInfo wskaźnikiem iconInfo należącym do parsera (windowIcon->iconInfo). Po zakończeniu wywołania zwrotnego parsera, update_recv_window_info_order() zwalnia window_icon.iconInfo, ale zakolejkowana asynchroniczna wiadomość nadal przechowuje i później wysyła ten nieaktualny wskaźnik. Złośliwy lub skompromitowany serwer RDP wysyłający spreparowane RAIL Window Alternate Secondary Order z WINDOW_ORDER_ICON może wywołać use-after-free, prowadząc do uszkodzenia pamięci i awarii klienta.