Katalog podatności CVE

Adminer 4.16.0 do 6.0.1 zawiera podatność SSRF przed uwierzytelnieniem w opcjonalnym sterowniku Elasticsearch (plugins/drivers/elastic.php), naprawioną w 6.0.2. Ponieważ adminer/include/auth.inc.php wywołuje Driver::connect() przed walidacją wyniku logowania, nieuwierzytelniony atakujący może wysłać spreparowane parametry auth[server], auth[username] i auth[password], powodując, że serwer Adminer wyśle żądanie HTTP GET do dowolnego osiągalnego hosta i portu. Sterownik nie blokuje adresów loopback, prywatnych, link-local ani innych zastrzeżonych; jeśli nie podano portu, dodaje domyślny 9200, a ogólna kontrola portów odrzuca porty poniżej 1024. Wybrane pola błędów JSON z odpowiedzi innych niż 2xx oraz błędy połączenia są renderowane na stronie logowania, co umożliwia skanowanie portów i rozpoznanie wewnętrznej sieci. Wymaga to wdrożenia opcjonalnego sterownika Elasticsearch i włączenia allow_url_fopen.

Adminer przed wersją 6.0.2 zawiera podatność cross-site scripting, gdzie wynik CONNECTION_ID() z bazy danych jest interpolowany do JavaScript bez odpowiedniego escapowania, co pozwala złośliwemu serwerowi bazy danych na wykonanie dowolnego JavaScript w uwierzytelnionym kontekście Adminer. W środowiskach współlokowanych, gdzie baza danych ma uprawnienia FILE i może zapisywać do katalogu głównego WWW, atakujący mogą użyć XSS do wysyłania uwierzytelnionych żądań SQL, które zapisują pliki PHP przez INTO DUMPFILE, osiągając zdalne wykonanie kodu jako konto serwera WWW.

Hugo, generator stron statycznych, w wersjach od v0.56.0 do v0.165.x renderuje pliki treści o typie media text/org bez escapowania surowego HTML. Bloki eksportu Org oraz fragmenty @@html:...@@ przepuszczają HTML bez escapowania, co prowadzi do cross-site scripting (XSS) w generowanej witrynie. Luka dotyczy tylko stron, których plik źródłowy lub wynik adaptera treści deklaruje typ text/org; wersja v0.166.0 naprawia problem, wprowadzając allowlistę security.allowContent, która domyślnie blokuje text/org.

Hugo w wersjach od 0.75.0 do 0.165.x zawiera podatność typu stored cross-site scripting: highlighter składni nie escapuje opcji lineAnchors przed przekazaniem jej do Chromy, który zapisuje wartość dosłownie w atrybutach id i href generowanego znacznika numerów linii. Spreparowana wartość lineAnchors podana jako atrybut bloku kodu Markdown (lub przekazana do funkcji szablonu highlight) skutkuje nieescapowanym HTML w renderowanej stronie, co pozwala na wykonanie dowolnego JavaScriptu w przeglądarkach odwiedzających. Luka naprawiona w 0.166.0 poprzez escapowanie HTML wartości lineAnchors przed przekazaniem do Chromy.

GitPython przed wersją 3.1.62 nie waliduje pola path odczytywanego z niezaufanego pliku .gitmodules podczas aktualizacji submodułów. Podczas gdy wcześniejsza poprawka (GHSA-hmq2-w58f-27jc) dodała Submodule._validated_name() ograniczające pole name, a wewnętrzny mechanizm ochrony Submodule._to_relative_path() jest stosowany w add() i move(), metoda Submodule.update() wyznacza bezwzględną lokalizację checkout z surowej wartości path bez tej ochrony. Wpis .gitmodules zawierający komponenty przejścia katalogowego (np. path = ../../../tmp/escaped) może spowodować tworzenie katalogów przez os.makedirs() poza drzewem roboczym repozytorium, wypełnienie ich z URL submodułu oraz usunięcie przez shutil.rmtree() przy użyciu force_remove. Luka naprawiona w GitPython 3.1.62.

Budibase server przed wersją 3.45.0 zawiera podatność cross-tenant information disclosure w endpoincie GET /api/applications/:appId/appPackage, która pozwala uwierzytelnionym użytkownikom odczytać metadane aplikacji i kod źródłowy innego tenanta. Atakujący może podać identyfikator aplikacji ofiary, aby bez kontroli autoryzacji uzyskać wrażliwe szczegóły aplikacji, w tym strukturę nawigacji, nazwy ról, wewnętrzne adresy URL ekranów, fragmenty JavaScript i identyfikatory użytkowników.

Budibase Server przed wersją 3.45.0 nie redaguje jawnych poświadczeń źródeł danych przed rozgłaszaniem aktualizacji tabel zewnętrznych do pokoju websocket współpracy Builder. Atakujący z dostępem do Builder mogą przechwycić nieocenzurowane obiekty źródeł danych zawierające hasła do baz danych i klucze API, obserwując operacje zapisu lub usunięcia tabeli.

Budibase przed wersją 3.45.0 zawiera nieuwierzytelnioną podatność server-side request forgery i eksfiltracji poświadczeń w endpoincie webhook Microsoft Teams, który przyjmuje sfałszowane aktywności Bot Framework z dowolnymi wartościami serviceUrl. Atakujący może wysłać spreparowane żądanie POST, aby wstrzyknąć kontrolowany przez siebie serviceUrl, który jest utrwalany i używany do wszystkich kolejnych odpowiedzi bota, powodując wysyłanie aktywnych tokenów dostępu Microsoft OAuth w nagłówkach Authorization do hosta atakującego oraz umożliwiając ślepy dostęp do sieci wewnętrznej.

Wersje stoatchat przed 0.15.5 nie egzekwują limitów prób na poziomie konta przy wyzwaniach MFA podczas logowania, ograniczając się jedynie do limitu opartego na adresie IP. Atakujący znający hasło może odgadywać kody TOTP, ponownie wykorzystując bilety wyzwania MFA i rozkładając próby na wiele adresów IP, aby obejść ograniczenia i uzyskać dostęp do konta.

Wersje stoatchat przed 0.15.5 zawierają podatność umożliwiającą enumerację kont w punkcie końcowym logowania, ujawniającą lokalizacje plików źródłowych w odpowiedziach błędów. Nieuwierzytelniony atakujący może rozróżnić zarejestrowane i niezarejestrowane adresy e-mail, porównując pola lokalizacji błędów zwracane z żądań POST /api/auth/session/login.

Wersje stoatchat przed 0.15.5 zawierają podatność typu denial of service w workerze potwierdzeń przetwarzającym wiadomości z masowymi wzmiankami. Uwierzytelniony użytkownik może wysłać pięć spreparowanych wiadomości z wzmiankami ról, aby zakończyć wszystkie workery potwierdzeń, wyłączając powiadomienia push i odznaki wzmianek w całym wdrożeniu do czasu restartu procesu API.

Wersje stoatchat przed 0.15.5 nie ponownie walidują nazw użytkowników po sanityzacji Unicode, umożliwiając atakującym tworzenie nazw z zabronionymi znakami poprzez podanie liter Unicode, które przekształcają się w odrzucone znaki. Atakujący mogą obejść listy dozwolonych znaków i limity długości, tworząc nazwy łudząco podobne do zarezerwowanych, osadzając znaki specjalne i przekraczając limit 32 znaków.

Grav 2.0.0 do 2.0.24 zawiera lukę w sandboxie Twig, która pozwala na ominięcie zabezpieczeń. Filtr `array` jest dozwolony w sandboxie, ale nie sprawdza listy dozwolonych metod, co umożliwia odczytanie prywatnych danych kontenera DI, w tym pełnej konfiguracji z sekretami (hasła, klucze OAuth, SMTP, Redis, proxy).

grav-plugin-login (wtyczka logowania do Grav CMS) w wersjach >= 3.8.7 i < 3.9.7 pozwala na ominięcie wyzwania dwuskładnikowego uwierzytelniania (2FA) dla treści chronionych funkcją Twig `authenticated()` lub shortcode `[authenticated]`. Na stronach z włączonym 2FA, `Login::isAuthenticated()` sprawdza tylko flagę sesji oznaczającą pomyślny krok hasła, a nie flagę oznaczającą pełne zalogowanie, więc sesja na etapie podawania kodu 2FA jest traktowana jako w pełni uwierzytelniona. Atakujący znający hasło członka, ale nie mogący odpowiedzieć na drugi czynnik, może czytać treści dostępne tylko dla członków.

Kodek HTTP/3 Netty (io.netty:netty-codec-http3) w wersjach od 4.2.0.Final do 4.2.17.Final nie egzekwuje wymogu RFC 9114, aby pole pseudo-nagłówka :authority i pole nagłówka host, gdy oba są obecne, miały tę samą wartość. Zdalny nieuwierzytelniony peer może wysłać pojedynczą ramkę HEADERS zawierającą oba pola z różnymi, kontrolowanymi przez atakującego wartościami; żądanie jest akceptowane i dostarczane do aplikacji z dwoma sprzecznymi autorytetami, co pozwala obejść decyzje dotyczące routingu, wirtualnych hostów i kontroli dostępu, gdy różne komponenty w ścieżce żądania konsultują różne pola. Problem naprawiono w 4.2.18.Final.

vLLM przed 0.29.0 akceptuje kontrolowane przez użytkownika stop_token_ids w punktach końcowych POST /v1/completions i POST /v1/chat/completions zgodnych z OpenAI, ale waliduje tylko to, że wartości są liczbami całkowitymi, a nie to, czy każdy identyfikator tokenu mieści się w zakresie słownika/modelu logits. Gdy min_tokens > 0, identyfikatory tokenów stop są używane jako indeksy logits do tłumienia tokenów stop, więc identyfikator spoza zakresu trafia do operacji indeksowania CUDA (index_put_) i wywołuje asercję po stronie urządzenia. Uwierzytelniony użytkownik API może wysłać pojedyncze nieprawidłowe żądanie uzupełnienia, które zwraca 500 Internal Server Error i wprowadza EngineCore w stan krytyczny, powodując awarię kolejnych żądań do czasu restartu usługi (odmowa usługi).

W vLLM w wersjach od 0.22.1 do 0.28.0, przypięcie rewizji modelu (--revision / --code-revision) nie jest propagowane do niektórych ładowań artefaktów Hugging Face dla architektur FunAudioChat i Tarsier2. Powoduje to, że wdrożenia przypięte do sprawdzonej rewizji nadal pobierają procesory, tokenizatory i konfiguracje z domyślnej rewizji repozytorium, co może zmienić przetwarzanie audio, zachowanie tokenizatora mowy lub konfigurację Tarsier2 bez zmiany skonfigurowanego przypięcia. Jest to problem integralności łańcucha dostaw i powtarzalności, ale nie stanowi zdalnego wykonania kodu ani obejścia trust_remote_code=False. Problem został naprawiony w wersji 0.28.0.

vLLM w wersjach 0.22.0–0.23.0 nie waliduje stop_token_ids względem zakresu słownika w frontendach Rust HTTP i gRPC, co pozwala identyfikatorom tokenów spoza słownika dotrzeć do MinTokensLogitsProcessor. Atakujący może wysłać żądanie z min_tokens większym od zera i nieprawidłowym stop_token_ids, wywołując błąd indeksowania tensora CUDA i wprowadzając EngineCore w stan krytyczny wymagający restartu usługi.

vLLM przed 0.29.0 nie wymusza walidacji długości promptu dekodera na endpointcie disaggregated serving /inference/v1/generate. Gdy żądanie zawiera ładunek 'features' (multimodalny), token_ids dostarczone przez klienta nie są sprawdzane względem model_config.max_model_len, a dla procesorów multimodalnych ze skip_prompt_length_check=True zbyt długi prompt trafia do bufora wejściowego workera o stałej szerokości max_model_len. Klient mogący dosięgnąć endpointu może wywołać awarię workera i odmowę usługi.

vLLM do 0.29.0 pobiera i w pełni materializuje zdalne lub inline media przed zastosowaniem udokumentowanych ograniczeń (limit rozmiaru skompresowanego audio VLLM_MAX_AUDIO_CLIP_FILESIZE_MB, domyślnie 25 MB, oraz limity --limit-mm-per-prompt). Na czterech ścieżkach wejściowych serwer odczytuje całe ciało odpowiedzi HTTP, dekoduje base64 lub tworzy zadanie pobrania na każdą część mediów, a dopiero potem stosuje limit (lub wcale). Zdalny atakujący może wywołać wyczerpanie pamięci i pasma przed odrzuceniem żądania (denial of service).