Katalog podatności CVE

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

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 przed v3.8.4 zawiera pominięcie autoryzacji w handlerze IPC siyuan-get, które pozwala zdalnym rendererom jądra uzyskać dostęp do natywnych formatów schowka poprzez wywołanie komend clipboardReadMathML, clipboardReadOffice i clipboardReadWPS z pasującym plaintextem. Atakujący kontrolujący treść zdalnego renderera może uzyskać formuły MathML, bajty Office i bajty WPS z lokalnego schowka podczas operacji wklejania inicjowanej przez użytkownika.

SiYuan przed v3.8.4 zawiera podatność na obejście uwierzytelniania w usłudze publikowania, gdzie ciasteczka sesji są wydawane bez atrybutów Secure i SameSite przez połączenia plaintext HTTP. Atakujący w ścieżce może przechwycić ważne ciasteczko publish-visitor-session-id z wymiany Basic Auth i odtworzyć je, aby uzyskać dostęp do uwierzytelnionych endpointów publikowania bez znajomości hasła.

SiYuan przed v3.8.4 nie waliduje nadawcy ani nie ogranicza odbiorców w handlerze IPC 'siyuan-send-windows' procesu głównego Electron (app/electron/main.js). Handler ignoruje event.sender i przekazuje każdy ładunek do wszystkich okien BrowserWindow zwracanych przez BrowserWindow.getAllWindows(), w tym okien innych otwartych obszarów roboczych. Renderer połączony ze zdalnym jądrem kontrolowanym przez atakującego może wysłać {cmd: "lockscreenByMode"} i wywołać wielokrotne blokowanie niepowiązanych lokalnych okien obszarów roboczych, powodując ograniczoną odmowę usługi.

SiYuan w wersjach 3.8.0–3.8.3 stosuje zabezpieczenie wrażliwych ścieżek w narzędziu plikowym MCP (util.IsForbiddenAbsPath() wywoływane z resolvePath()) tylko do dozwolonego katalogu głównego operacji rekurencyjnych, a nie do każdej rozwiązywanej ścieżki potomnej — niekompletna poprawka GHSA-c8r8-95hg-mp34. Uwierzytelniony administrator używający Agenta w aplikacji lub zewnętrznego serwera MCP może obejść denylistę chronionych plików obszaru roboczego: file.grep może zwracać pasujące linie z chronionych potomków, file.copy może kopiować chronionych potomków do zwykłej ścieżki, a unzip może nadpisywać chronionych potomków. Naprawiono w wersji 3.8.4.

Parse Server w wersjach >= 9.0.0 i < 9.10.1-alpha.8 oraz < 8.6.89 ocenia uprawnienie protectedFields na poziomie klasy względem niekompletnie rozwiązanego kontekstu wywołującego: role subskrybenta nie są rozwiązywane, a gdy subskrypcja nie dostarcza własnego tokenu sesji, ładunek zdarzenia jest redagowany względem tożsamości anonimowej, mimo że odczyt był autoryzowany względem połączonego użytkownika. W rezultacie maski pól zdefiniowane dla roli, uwierzytelnionych użytkowników lub konkretnego użytkownika nie są stosowane, więc uwierzytelniony subskrybent może otrzymywać wartości pól, które REST API poprawnie ukrywa. Dotyczy tylko klas z włączonym LiveQuery, które definiują protectedFields w grupach role:, authenticated lub per-user; maski w grupie public (*) są stosowane poprawnie. Naprawiono w 9.10.1-alpha.8 i 8.6.89.

AVideo przed wersją 29.1.0 zawiera podatność trwałego skryptu krzyżowego (stored XSS) w polu trailer1 wideo, renderowanym bez sanityzacji wewnątrz wbudowanego łańcucha JavaScript onclick. Atakujący z uprawnieniem do przesyłania wideo mogą zapisać ładunki zakodowane encjami HTML, które omijają walidację isValidURL() i są dekodowane przez przeglądarkę, co pozwala na wyjście z łańcucha JavaScript i wykonanie dowolnego kodu w sesji każdego odwiedzającego, w tym administratorów.

Capgo (backend capgo.app) przed wersją 12.127.5 zawiera błąd autoryzacji w punkcie końcowym PATCH /private/role_bindings/:binding_id. Handler sprawdza jedynie rangę nowo przypisywanej roli, ale nie weryfikuje rangi roli aktualnie powiązanej z danym bindingiem, co pozwala użytkownikowi z rolą org_admin (ranga 90) obniżyć uprawnienia org_super_admin (ranga 95) do roli niższej, np. org_member (ranga 75).

capgo.app przed wersją 12.128.12 nie egzekwuje polityki wygaśnięcia kluczy API organizacji podczas tworzenia kluczy API o zasięgu aplikacji. W punkcie końcowym POST /apikey żądania podające app_id, ale pomijające org_id, limited_to_orgs i expires_at, nie dodają organizacji właściciela aplikacji do listy sprawdzanej przez validateExpirationAgainstOrgPolicies, co pozwala uwierzytelnionemu członkowi organizacji utworzyć klucz API bez daty wygaśnięcia.

capgo do wersji 12.128.2 zawiera podatność typu insecure direct object reference w punkcie końcowym PUT /app/:appId, który akceptuje ścieżki przechowywania ikon kontrolowane przez atakującego. Uwierzytelnieni użytkownicy mogą podać dowolne ścieżki w prywatnym bucketcie obrazów i uzyskać URL-e podpisane kluczem service-role ważne 7 dni, umożliwiające odczyt obiektów innych dzierżawców, w tym awatarów użytkowników, logotypów organizacji i ikon aplikacji.

Capgo.app przed wersją 12.264.5 nie egzekwuje wygaśnięcia przesyłania ani stanu cyklu życia kompilacji w punkcie końcowym proxy TUS /build/upload/:jobId. Mimo że przy tworzeniu żądania kompilacji natywnej zapisywany jest znacznik upload_expires_at (jedna godzina) i status 'pending', proxy ładuje tylko wybrane pola i sprawdza jedynie uprawnienie app.build_native, co pozwala uwierzytelnionemu użytkownikowi kontynuować zapis do sesji przesyłania po upływie terminu lub po zakończeniu fazy przesyłania.

Capgo (capgo.app) zawiera niekompletne egzekwowanie kontroli dostępu/blokady treści we wszystkich wersjach; brak dostępnej poprawki. Blokada treści w supabase/schemas/prod.sql zwalnia wiersze app_versions, których poprzedni storage_provider to r2-direct, pozostawiając krytyczne kolumny jako modyfikowalne, a endpoint /updates nie wyklucza wersji r2-direct, co pozwala atakującemu z uprawnieniem do zapisu/przesyłania bundle modyfikować metadane i dostarczać zmienione bundle do urządzeń.

capgo.app to platforma aktualizacji OTA dla aplikacji Capacitor. We wszystkich wersjach przed poprawką polityka row-level security UPDATE na tabeli public.orgs pozwala administratorowi organizacji (z uprawnieniem org.update_settings) zaktualizować cały wiersz, w tym wewnętrzną kolumnę customer_id. Wysyłając aktualizację bezpośrednio do Supabase PostgREST, administrator org bez uprawnienia org.update_billing może wyzerować lub uszkodzić wskaźnik klienta Stripe, powodując błędy kontroli planu i rozliczeń.