Katalog podatności CVE

Wersje SiYuan przed v3.8.4 zawierają podatność typu path traversal w endpointcie checkoutRepo, która pozwala uwierzytelnionym administratorom zapisywać pliki JSON poza obszarem roboczym. Atakujący może podać parametr sessionID zawierający sekwencje przejścia katalogowego, aby nadpisać dowolne pliki JSON w istniejących katalogach zapisywalnych przez jądro poza granicami workspace.

Wersje SiYuan przed v3.8.4 zawierają podatność typu path traversal w endpointcie exportBrowserHTML, która pozwala uwierzytelnionym administratorom zapisywać dowolną treść HTML do pliku index.html poza katalogiem workspace. Atakujący może podać parametr folder z sekwencjami przejścia katalogowego, aby wydostać się z katalogu eksportu i nadpisać index.html w dowolnej istniejącej lokalizacji zapisywalnej przez jądro, co umożliwia trwały XSS lub defacement workspace.

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.

Parse Server, backend typu open source, w wersjach przed 8.6.90 oraz od 9.0.0 przed 9.10.1-alpha.9, ma podatność w logice deduplikacji tokenów urządzeń dla rekordów instalacji. Logika ta nie sprawdza typu pól dostarczanych przez klienta przed użyciem ich do budowania zapytań do bazy danych. Nieuwierzytelniony atakujący, znający tylko publiczny identyfikator aplikacji, może przesłać wartości niebędące ciągami znaków, aby wstrzyknąć operatory zapytań, co powoduje, że czyszczenie deduplikacji (wykonywane z podwyższonymi uprawnieniami) usuwa wszystkie rejestracje urządzeń w aplikacji lub wybrany podzbiór.

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 (Cap-go/capgo.app) backend Supabase functions zawierają wadę autoryzacji w ścieżce promocji pakietów API-key. Endpoint PUT /bundle, dostępny dla kluczy API "all" i "write", wywołuje setChannel, który autoryzuje za pomocą checkPermission(c, 'channel.promote_bundle', { appId: body.app_id }) i pomija channel_id z żądania. Ponieważ pominięte pole zakresu jest przekazywane jako SQL NULL, a ocena nadpisań zakresu kanału jest warunkowana na p_channel_id IS NOT NULL, nadpisania per-channel nie są oceniane. Posiadacz uprawnień app-level channel.promote_bundle (domyślnie przyznawanych rolom app_developer i app_uploader) może promować pakiet do kanału z jawnym zakazem per-channel, aktualizując public.channels.version.

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 (capgo.app) udostępnia natywny proxy przesyłania TUS dla kompilacji (supabase/functions/_backend/public/build/upload.ts), który autoryzuje wywołującego względem pojedynczego zadania kompilacji identyfikowanego przez podane builder_job_id i waliduje tylko zapisany upload_path tego zadania, ale następnie przekazuje kontrolowany przez użytkownika sufiks zasobu TUS pobrany z /build/upload/:jobId/* do usługi builder, wstrzykując uprzywilejowany klucz API buildera Capgo. Ponieważ przekazywany sufiks nigdy nie jest powiązany z upload_path lub upload_session_key autoryzowanego zadania, wywołujący posiadający ważny klucz API Capgo 'all' lub 'write' z uprawnieniem app.build_native dla jednej aplikacji może użyć swojej autoryzowanej ścieżki proxy dla zadania A do zapisu w zasobie przesyłania TUS innego zadania B, pod warunkiem że sufiks zasobu jest znany lub ujawniony, uszkadzając artefakty tej kompilacji. Wszystkie wersje są podatne; w momencie publikacji biuletynu nie było dostępnej poprawki.

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) udostępnia starą tabelę członkostwa public.org_users bezpośrednio przez Supabase PostgREST. Polityki bezpieczeństwa na poziomie wierszy "Allow org admin to insert" i "Allow org admin to update" tylko sprawdzają, czy wywołujący ma uprawnienia administratora w docelowej organizacji, nie wymagają zaproszenia w tmp_users, akceptacji tokena zaproszenia ani żadnych działań docelowego użytkownika. W rezultacie uwierzytelniony administrator organizacji może bezpośrednio INSERT lub UPDATE wiersze org_users, dodając dowolne istniejące konto public.users jako aktywnego członka z uprawnieniami admin, omijając cały proces zaproszeń i przypisywania ról.

capgo.app do wersji 12.129.0 nie weryfikuje statusu usunięcia podczas serwowania artefaktów pakietów z pamięci podręcznej z publicznego endpointu odczytu plików. Nieuwierzytelnieni atakujący mogą pobierać usunięte pakiety za pomocą adresów URL z pamięci podręcznej i wywołać przywrócenie usuniętych obiektów do magazynu R2 przy trafieniach w pamięć podręczną.

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 CLI (pakiet npm @capgo/cli) do wersji 7.98.2 jest dotknięty problemem nadmiernych uprawnień konta usługi w przepływie onboardingu Android. Podczas onboardingu przez Google OAuth CLI zaprasza wygenerowane konto usługi Google Play z uprawnieniem na poziomie całego konta CAN_MANAGE_DRAFT_APPS_GLOBAL (przekazywanym jako developerAccountPermissions w żądaniu utworzenia użytkownika Android Publisher API), mimo że interfejs użytkownika informuje o zaproszeniu do pojedynczej aplikacji z uprawnieniami tylko do wydania. W rezultacie każdy, kto uzyska klucz wygenerowanego konta usługi (PLAY_CONFIG_JSON), może tworzyć, edytować i usuwać aplikacje robocze w całym koncie deweloperskim Google Play, a nie tylko w wybranej paczce.

Capgo (capgo.app) blokuje bezpośrednie wstawianie użytkowników do tabeli public.manifest za pomocą restrykcyjnej polityki bezpieczeństwa na poziomie wiersza, ale to ograniczenie można obejść pośrednio. Podmiot posiadający klucz API o zakresie aplikacji upload/write/all (uprawnienia upload+) lub uwierzytelniony użytkownik z uprawnieniami write+ na aplikacji może zaktualizować public.app_versions.manifest dla wersji, której storage_provider to 'r2-direct', co nie jest objęte kontrolą blokady zawartości pakietu. Asynchroniczny worker on_version_update ufa record.manifest i używając klienta Supabase z rolą usługi, wstawia kontrolowane przez atakującego file_name, file_hash i s3_path do public.manifest przed wyczyszczeniem app_versions.manifest. Gdy kanał wskazuje na spreparowaną wersję, endpoint /updates zwraca wpis manifestu utworzony przez rolę usługi jako download_url dla klienta, umożliwiając zatrucie manifestu OTA przez zaufaną ścieżkę asynchronicznego workera. Wszystkie wersje są podatne; w momencie publikacji biuletynu nie było dostępnej poprawki.

Capgo (capgo.app) jest dotknięty błędem autoryzacji w ścieżce aktualizacji ikony aplikacji. Endpoint PUT /app/:id akceptuje kontrolowaną przez użytkownika wartość `icon`, normalizuje ją i przechowuje w public.apps.icon_url bez weryfikacji, czy ścieżka obrazu należy do własnej przestrzeni nazw obrazów docelowej aplikacji (np. org/{owner_org}/{app_id}/...). Aktualizacja apps.icon_url wyzwala trigger on_app_update, którego worker odczytuje record.icon_url i wywołuje cleanStoredImageMetadata(), który działa z poświadczeniami roli usługi (supabaseAdmin()) i pobiera oraz ponownie przesyła referencyjny obiekt magazynu z upsert: true. W rezultacie uwierzytelniony posiadacz klucza API z ograniczonym zapisem do aplikacji może spowodować, że uprzywilejowany worker nadpisze prywatny obiekt obrazu poza zakresem (na przykład logo organizacji), którego klucz nie może odczytać ani zapisać bezpośrednio w ramach Supabase Storage RLS. Wszystkie wersje są podatne; w momencie publikacji biuletynu nie było dostępnej wersji z poprawką.