Katalog podatności CVE

Luka XSS w luci-app-https-dns-proxy pozwala uwierzytelnionym użytkownikom wstrzyknąć aktywny HTML przez parametr resolver_url. Podczas przeglądania strony statusu HTTPS DNS Proxy przez administratora, URL resolvera jest renderowany jako surowy HTML i wykonuje JavaScript w kontekście przeglądarki administratora.

ArcadeDB przed wersją 26.7.2 nie zaciemnia tokena klastra w odpowiedzi GET /api/v1/server, umożliwiając uwierzytelnionym użytkownikom odczytanie arcadedb.ha.clusterToken w postaci jawnego tekstu. Atakujący mogą użyć wyciekłego tokena z nagłówkami X-ArcadeDB-Cluster-Token i X-ArcadeDB-Forwarded-User do podszycia się pod roota i wykonania działań administracyjnych, w tym tworzenia użytkowników, operacji na bazie danych i wyłączenia serwera.

ArcadeDB przed wersją 26.7.2 (arcadedb-engine) umożliwia skryptom wyzwalaczy odwoływanie się do klas hosta w java.lang.* (poprzez Java.type), ponieważ ScriptTriggerExecutor dodaje java.lang.* do dozwolonych pakietów. Uwierzytelniony użytkownik z uprawnieniami UPDATE_SCHEMA może utworzyć wyzwalacz JavaScript, który wywołuje java.lang.Runtime.getRuntime().exec() (lub ProcessBuilder), osiągając wykonanie poleceń systemu operacyjnego po uruchomieniu wyzwalacza.

better-auth przed wersją 1.6.11 zawiera niebezpieczne domyślne ustawienia kryptograficzne w pluginach oidcProvider i mcp, które reklamują algorytm none i domyślnie akceptują zwykły PKCE. Atakujący mogą wykorzystać negocjację algorytmów do zaakceptowania niepodpisanych tokenów lub przechwycenia kodów autoryzacyjnych, gdy używany jest zwykły PKCE zamiast wymaganej metody S256.

better-auth przed wersją 1.6.13 (oraz wersje pre-release 1.7.0-beta.0 do 1.7.0-beta.3) nie waliduje schematu redirect_uris zarejestrowanych przez przestarzały plugin oidc-provider oraz plugin mcp. Atakujący może zarejestrować klienta OAuth z redirect_uri o schemacie javascript:, który serwer autoryzacyjny zwraca bez zmian w odpowiedzi na zgodę. Jeśli strona zgody przekierowuje przeglądarkę do zwróconego redirectURI (np. przypisując go do window.location.href), JavaScript atakującego wykonuje się w kontekście serwera autoryzacyjnego, ujawniając sesję ofiary i umożliwiając przejęcie konta.

better-auth SCIM w wersjach od 1.5.0 do 1.7.0-beta.3 domyślnie nie wiąże dostawców SCIM spoza organizacji z ich twórcą, umożliwiając uwierzytelnionym użytkownikom zarządzanie dostawcami innych użytkowników. Atakujący mogą regenerować tokeny SCIM, unieważniać prawidłowe tokeny i uwierzytelniać się do interfejsów API SCIM przy użyciu kontrolowanego przez siebie tokena.

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