Katalog podatności CVE

Kodek HTTP/3 w Netty (netty-codec-http3) od 4.2.2.Final do 4.2.17.Final nie obsługuje specjalnie metody CONNECT z formą authority-form, co prowadzi do tworzenia wadliwych żądań CONNECT w HTTP/3 z autorytetem kontrolowanym przez atakującego.

Kodek HTTP/3 w Netty (netty-codec-http3) od 4.2.0.Final do 4.2.17.Final zawiera podatność na niekontrolowane zużycie zasobów w dekoderze instrukcji strumienia QPACK, pozwalając atakującemu na zadeklarowanie ogromnej długości literału, co prowadzi do nieograniczonego wzrostu bufora i wyczerpania pamięci (OOM).

Dekoder prefiksowanych liczb całkowitych QPACK w Netty (netty-codec-http3) od 4.2.0.Final do 4.2.17.Final nie ogranicza liczby bajtów kontynuacji, co pozwala atakującemu na wywołanie wysokiego zużycia CPU (O(N^2)) i wzrostu pamięci, prowadząc do OOM i zagłodzenia event-loop.

Kodek HTTP/3 w Netty (netty-codec-http3) od 4.2.0.Final do 4.2.17.Final przetrzymuje nieograniczony stan enkodera QPACK dla każdego strumienia, co przy braku potwierdzeń sekcji pozwala na nieograniczony wzrost pamięci i wyczerpanie zasobów (DoS).

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.

CVE zostało odrzucone jako duplikat. Brak dalszych informacji o podatności.

CVE zostało odrzucone jako duplikat. Brak dalszych informacji o podatności.

CVE zostało odrzucone jako duplikat. Brak dalszych informacji o podatności.

CVE zostało odrzucone jako duplikat. Brak dalszych informacji o podatności.

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

vLLM przed wersją 0.29.0 zawiera podatność obejścia limitu zasobów w alokacji dekodera PyNvVideoCodec, gdzie przesłanianie podklasy samplera pozwala na niezależne zwiększanie liczników. Nieuwierzytelnieni atakujący mogą wybierać różne podklasy samplera w żądaniach wideo, aby przekroczyć skonfigurowane limity dekodera i wyczerpać nieewidencjonowaną pamięć GPU.

vLLM przed 0.29.0 nie wymusza limitu VLLM_MAX_AUDIO_CLIP_FILESIZE_MB podczas dekodowania audio w czacie multimodalnym, co pozwala nieuwierzytelnionym klientom obejść ograniczenia rozmiaru pliku. Atakujący mogą przesyłać zbyt duże pliki audio przez endpointy czatu, zużywając nadmierne zasoby pamięci i CPU podczas dekodowania.

vLLM w wersjach przed 0.29.0 zawiera podatność na odmowę usługi w parametrze cache_salt przyjmowanym na endpointach zgodnych z OpenAI i Anthropic API, który nie ma walidacji maksymalnej długości i jest przetwarzany w pojedynczym wątku schedulera EngineCore. Nieuwierzytelnieni atakujący mogą wysyłać żądania HTTP z wartościami salt o rozmiarze setek megabajtów, wywołując kosztowną serializację pickle i hashowanie SHA-256, blokując wątek schedulera i odmawiając usługi wszystkim równoczesnym żądaniom.

SiYuan w wersjach do 3.8.3 włącznie ma błąd w mechanizmach uwierzytelniania (CheckAuth w kernel/model/session.go oraz IsSessionOriginAllowed w kernel/util/net.go), które zawodzą w bezpieczny sposób, gdy brakuje nagłówka Origin. Przeglądarki pomijają Origin przy nawigacjach GET cross-site top-level oraz ładowaniu podzasobów no-cors GET, a ciasteczko sesji ma SameSite=Lax, więc pojedyncze żądanie GET z wrogiej strony otrzymuje rolę RoleAdministrator. W połączeniu z sniffingiem typu zawartości na /api/network/proxy pozwala to nieuwierzytelnionemu zdalnemu atakującemu na wykonanie dowolnego skryptu w origin SiYuan, wywołanie API administratora i eksfiltrację tokenu API.

SiYuan w wersjach 3.7.0 do 3.8.4 zawiera podatność stored XSS w rendererach galerii i baz danych kanban, gdzie opisy pól nie są escapowane w atrybutach aria-label. W aplikacji desktopowej Electron z włączonym nodeIntegration atakujący może wstrzyknąć JavaScript wywołujący API Node.js child_process w celu wykonania dowolnych poleceń z uprawnieniami użytkownika.

SiYuan przed wersją 3.8.4 zawiera podatność SQL injection w punkcie końcowym zapytań grafowych, gdzie parametr dailyNoteSavePath jest łączony z SQL bez escapowania. Nieuwierzytelnieni atakujący na opublikowanych stronach z wyłączonym uwierzytelnianiem mogą wstrzyknąć SQL poprzez UNION SELECT, aby wyodrębnić dowolne wiersze z bazy danych ze wszystkich notatników.