Katalog podatności CVE

SiYuan w wersjach przed 3.8.4 zawiera podatność path traversal w punkcie końcowym setNotebookIcon, która pozwala uwierzytelnionym administratorom tworzyć dowolne drzewa katalogów i zapisywać pliki poza granicami przestrzeni roboczej. Atakujący mogą podać sekwencje przejścia katalogów w parametrze notebook, aby wyjść z katalogu danych przestrzeni roboczej i zapisać pliki conf.json w dowolnych lokalizacjach dostępnych dla procesu jądra.

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.

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.

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

Cap-go capgo.app nie weryfikuje, czy podmioty w channel_permission_overrides należą do organizacji, co pozwala uwierzytelnionym administratorom aplikacji/organizacji przyznawać uprawnienia kanału użytkownikom niebędącym członkami. Atakujący z uprawnieniami administratora może wstawiać wiersze nadpisań z dowolnymi zewnętrznymi UUID użytkowników, aby przyznać uprawnienia na poziomie kanału, takie jak channel.promote_bundle, użytkownikom spoza organizacji.

W Cap-go capgo.app przed wersją 12.267.1 nie jest poprawnie weryfikowany poziom uprawnień celu podczas rotacji kluczy API. Użytkownik z rolą apikey_manager może obrócić klucz o wyższych uprawnieniach (org_super_admin) i odzyskać jego tekst jawny.

Capgo przed wersją 12.244.1 zawiera podatność integralności między dzierżawcami w procesie czyszczenia metadanych, który ufa kluczom obiektów obrazów z mutowalnych wierszy bazy danych bez weryfikacji własności.

Capgo (capgo.app) do wersji 12.261.0 zawiera niekompletną poprawkę kontroli dostępu dla tabeli public.sso_providers. Migracja 20260826100000_sso_providers_block_direct_active_insert.sql instaluje wyzwalacz BEFORE UPDATE (enforce_sso_provider_client_update_guard()), który blokuje tylko kolumny dns_verified_at, domain, status i enforce_sso, pozostawiając kolumnę provider_id (oraz metadata_url i attribute_mapping) możliwą do zapisu. Ponieważ tabela ma przyznane uprawnienie ALL dla ról anon i authenticated bez ograniczeń na poziomie kolumn, a polityki row-level security (np. allow_org_admins_update_sso_providers) ograniczają tylko które wiersze mogą być aktualizowane, a nie które kolumny, użytkownik z uprawnieniem org_admin (org.update_settings) może przez PostgREST zmienić provider_id na kontrolowanego przez siebie dostawcę tożsamości. Ponieważ provider_id jest kotwicą zaufania wiążącą domenę e-mail z autoryzowanym IdP, atakujący może następnie uwierzytelnić się przez własny IdP, podając e-mail właściciela organizacji; dopasowanie po stronie serwera kończy się sukcesem, a procedura scalania przypisuje tożsamość SSO atakującego do istniejącego konta właściciela, zeruje jego hasło i usuwa inne tożsamości oraz sesje. Prowadzi to do eskalacji uprawnień z org_admin do właściciela organizacji/super_admin, przejęcia konta i zablokowania prawowitego właściciela. Eksploatacja wymaga aktywnego dostawcy SSO w organizacji docelowej oraz posiadania przez atakującego roli org_admin w tej organizacji. Brak dostępnej wersji z poprawką.

Flowise do wersji 3.1.4 udostępnia punkty GET /api/v1/upsert-history/:id i PATCH /api/v1/upsert-history bez kontroli uprawnień, a usługa nie weryfikuje przynależności do obszaru roboczego.

Flowise do wersji 3.1.4 nie wymusza autoryzacji na pulpicie administracyjnym BullMQ. Gdy serwer działa w trybie kolejki z włączonym pulpitem, każdy uwierzytelniony użytkownik może uzyskać dostęp do /admin/queues.

Flowise do wersji 3.1.4 identyfikuje użytkowników SSO i logowanych hasłem wyłącznie na podstawie adresu e-mail, bez wiązania dostawcy lub identyfikatora. Atakujący może zalogować się jako każdy istniejący użytkownik, używając jego adresu e-mail.

Flowise do wersji 3.1.4 zawiera obejście uwierzytelniania w ścieżce logowania SSO, gdy e-mail w wywołaniu zwrotnym pasuje do użytkownika ze statusem INVITED. Procedura kopiuje rekord użytkownika z tymczasowym tokenem do rejestracji, co pozwala na przejęcie zaproszenia.

Flowise do wersji 3.1.4 brakuje kontroli RBAC na trasach wiadomości czatu, co pozwala kluczom API o niskich uprawnieniach na odczyt i usunięcie historii czatu.

W projekcie CloudClassroom-PHP-PHP do konkretnego commita wykryto podatność SQL injection w pliku mydetailsfaculty.php poprzez argument myfid. Atak może być przeprowadzony zdalnie.