Katalog podatności CVE

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.

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

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

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

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

W aplikacji ClawHub (openclaw/clawhub) występuje podatność typu server-side request forgery (SSRF) w pobieraniu obrazów w publicznym podglądzie profilu. Podgląd przyjmuje dostarczony przez użytkownika URL obrazu i sprawdza tekstową nazwę hosta względem wzorców adresów prywatnych, ale nie waliduje ani nie przypina rozwiązanego adresu docelowego, więc publicznie wyglądająca nazwa hosta może rozwiązać się na adres wewnętrzny lub zmienić rozwiązywanie między walidacją a połączeniem (DNS rebinding).

Aplikacja ClawHub (openclaw/clawhub) nie wiąże anonimowych żądań HTTP API z zaufaną tożsamością wywołującego, więc wszystkie bezpośrednie anonimowe żądania API dzielą jeden domyślny limit quota. Zdalny, nieuwierzytelniony wywołujący może wyczerpać ten współdzielony limit i tym samym odmówić lub pogorszyć dostęp do API dla niezwiązanych odwiedzających. Dodatkowo, gdy opcja TRUST_FORWARDED_IPS jest włączona bez uwierzytelnionego edge/proxy, klienci mogą dostarczać dowolne nagłówki forwarded IP, aby wybierać tożsamości quota i omijać ograniczanie szybkości.