Katalog podatności CVE

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

capgo.app to platforma aktualizacji OTA dla aplikacji Capacitor. We wszystkich wersjach do bieżącej (brak poprawki) funkcja transfer_app() przenosi aplikację, jej kanały, wersje i powiązane rekordy do organizacji docelowej bez usuwania lub ponownej walidacji istniejących wierszy w channel_permission_overrides. W rezultacie użytkownik, który miał nadpisanie uprawnień kanału w organizacji źródłowej, zachowuje je po transferze, mimo braku członkostwa i powiązania RBAC w organizacji docelowej.

Capgo (backend capgo.app, wersje ≤ 12.261.0) niewłaściwie ogranicza role, które rola organizacji apikey_manager może przypisywać do nowo tworzonych kluczy API. Gdy uwierzytelniony użytkownik z rolą apikey_manager wywołuje POST /apikey, stosowane są tylko sprawdzenie uprawnienia org.manage_apikeys, stała lista zabronionych ról i porównanie rangi, ale nie sprawdza się, czy wywołujący faktycznie posiada uprawnienia przypisywanej roli. Ponieważ lista zabronionych pomija role wdrożeniowe, a apikey_manager ma rangę 78 wyższą niż te role, kontrola rangi również przechodzi.

Flowise (pakiety npm flowise i flowise-components) do wersji 3.1.4 wyszukuje poświadczenia po ID bez filtrowania według przestrzeni roboczej żądającego użytkownika w kilku ścieżkach kodu, m.in. getAllOpenaiAssistants/getSingleOpenaiAssistant, uploadFilesToAssistant, deleteAssistant i wspólnym helperze używanym przez getVoices. Uwierzytelniony użytkownik jednej przestrzeni roboczej może podać UUID poświadczenia należącego do innej przestrzeni, powodując odszyfrowanie i użycie klucza API OpenAI lub ElevenLabs tej przestrzeni w imieniu atakującego.

W aplikacji ClawHub (openclaw/clawhub) występuje błąd nieprawidłowej autoryzacji. Zasób (skill) należący do organizacji zachowuje identyfikator ownerUserId pierwotnego wydawcy, a mechanizmy autoryzacji transferu i cyklu życia ufają temu historycznemu użytkownikowi zamiast sprawdzać aktualne uprawnienia w organizacji. Uwierzytelniony użytkownik, który pierwotnie opublikował skill organizacji, może go przenieść, usunąć lub przywrócić nawet po odebraniu lub obniżeniu jego uprawnień organizacyjnych.

W aplikacji ClawHub (openclaw/clawhub) występuje błąd w przepływie moderacji zgłoszeń skilli. Cztery zwykłe uwierzytelnione konta mogą zgłosić widoczny skill i wywołać jego automatyczne ukrycie (moderationStatus: hidden) w katalogu bez decyzji moderatora. Ponieważ limit zgłaszającego liczy tylko zgłoszenia wobec widocznych celów, te same konta mogą powtarzać proces wobec kolejnych skilli; skille oficjalne nie są wyłączone.

W aplikacji ClawHub (openclaw/clawhub) brakuje kontroli autoryzacji w funkcji podglądu changelogu. Zalogowany wywołujący może użyć publicznej akcji skills:generateChangelogPreview dla skilla, do którego nie ma uprawnień; poprzednia wersja jest odczytywana bez autoryzacji odczytu plików, a do 8000 znaków poddanej kwarantannie treści może zostać przesłane do dostawcy AI i odzwierciedlone w podglądzie zwróconym wywołującemu, ujawniając zastrzeżoną treść skilla.