Podatności Capgo

W pakiecie npm `capgo` (do wersji 12.207.1) funkcja validateInvite() nie porównuje rangi roli zapraszającego z rangą roli, którą chce nadać. Użytkownik z uprawnieniem org.invite_user może zaprosić zewnętrzną osobę jako org_admin lub org_billing_admin, a akceptacja zaproszenia tworzy powiązanie roli z pominięciem mechanizmów ochronnych bazy danych.

Podatność w Capgo przed wersją 12.128.2 wynika z niebijectywnego dekodowania podwójnych podkreślników na kropki podczas parsowania nazw hostów wersji zapoznawczych. Atakujący mogą rejestrować identyfikatory aplikacji z podkreślnikami, które kolidują z identyfikatorami z kropkami innych dzierżawców, powodując błędne kierowanie wersji zapoznawczych i odmowę dostępu do wersji zapoznawczych dla ofiar.

Podatność w Capgo przed wersją 12.128.2 ujawnia informacje poprzez funkcję RPC get_orgs_v7(userid), która jest publicznie wywoływalna mimo zamierzonej prywatnej kontroli dostępu. Nieuwierzytelnieni atakujący mogą podać dowolne UUID użytkownika, aby pobrać dane o członkostwie w organizacjach, rolach, służbowych adresach e-mail i metadanych rozliczeniowych innych użytkowników.

Podatność w Capgo przed wersją 12.128.2 wynika z błędu autoryzacji w funkcji transfer_app(), która nie aktualizuje pola deploy_history.owner_org podczas przenoszenia aplikacji między organizacjami. Atakujący mogą wykorzystać to przeoczenie, aby zachować nieautoryzowany dostęp do historii wdrożeń w źródłowej organizacji lub spowodować utratę dostępu do przeniesionych rekordów wdrożeń w docelowej organizacji.

Podatność w Capgo przed wersją 12.128.2 pozwala kluczom API z ograniczeniami do przesyłania modyfikować pole app_versions.r2_path przez PostgREST, co umożliwia przekierowanie do dowolnych obiektów R2. Atakujący może ustawić r2_path na obiekt ofiary, usunąć swoją wersję i wywołać funkcję czyszczącą on_version_update, która usunie obiekt ofiary, powodując denial of service.

Podatność w Capgo przed wersją 12.128.2 umożliwia złamanie kontroli dostępu w API zarządzania organizacjami. Klucz API z ograniczeniem do konkretnych organizacji dziedziczy uprawnienia właściciela, co pozwala na destrukcyjne operacje międzyorganizacyjne.

Capgo w wersjach przed 12.128.2 zawiera podatność na ujawnienie informacji w nieautoryzowanym punkcie końcowym /updates, który rozwiązuje parametr defaultChannel przed nałożeniem ograniczeń prywatności. Umożliwia to atakującym enumerację prywatnych kanałów oraz ujawnienie stanu wersji i konfiguracji.

Capgo przed wersją 12.128.2 zawiera podatność na walidację poświadczeń w punkcie końcowym POST /functions/v1/private/validate_password_compliance, który można wywołać tylko za pomocą publicznego klucza Supabase bez uwierzytelnienia. Punkt końcowy jest zgodny z CORS i nie ma ograniczeń dotyczących liczby żądań, co umożliwia atakującym przeprowadzanie ataków typu password spraying i credential stuffing.

Capgo (capgo.app) nie ogranicza bezpośredniego dostępu zapisu do tabeli public.sso_providers udostępnionej przez Supabase PostgREST. Posiadacz zwykłego pełnego klucza API Capgo może wstawić wiersz ze statusem 'active' i enforce_sso=true, omijając zamierzoną ścieżkę provisioningu SSO i jej kontrole (wymóg planu Enterprise, tworzenie dostawcy przez Supabase Management API, weryfikację własności domeny przez DNS TXT, przejście statusów pending_verification → verified → active oraz wydanie zaufanego identyfikatora dostawcy przez Supabase Auth). Sfałszowany wiersz jest uznawany przez logikę wykrywania i wymuszania SSO, w tym nieuwierzytelniony endpoint preflight /private/sso/check-domain, który zgłasza {"has_sso": true, "enforce_sso": true} dla domen nigdy niezweryfikowanych.

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

Backend Capgo (do wersji 12.242.4) nie weryfikuje delegacji rodzic-podklucz przy przetwarzaniu nagłówka x-limited-key-id. Middleware ufa identyfikatorowi klucza API podanemu przez atakującego i może podstawić tożsamość oraz sekret klucza o wyższych uprawnieniach należącego do tego samego właściciela.

Capgo (Cap-go/capgo.app) zawiera obejście uwierzytelniania we wszystkich wersjach. Ścieżka autoryzacji Edge akceptuje sesję Supabase aal1 opartą tylko na haśle i przyznaje uprawnienia RBAC, mimo że konto ma zweryfikowany czynnik MFA, który nie został użyty w tej sesji.

Capgo nie usuwa nadpisań uprawnień kanałów po usunięciu ostatniego przypisania roli organizacyjnej użytkownika, pozostawiając aktywne nieaktualne nadpisania. Atakujący mogą zachować uprawnienia specyficzne dla kanału po odebraniu podstawowego dostępu RBAC i wykonywać nieautoryzowane działania, takie jak zmiana produkcyjnych wersji OTA.

Podatność w Capgo przed wersją 12.128.2 ujawnia informacje o organizacjach poprzez funkcję RPC Supabase PostgREST. Nieuwierzytelnieni atakujący mogą wyliczać identyfikatory organizacji, wysyłając zapytania z kluczem API i analizując różne komunikaty błędów.

Podatność w Capgo przed wersją 12.128.2 umożliwia nieuwierzytelnionym atakującym odczytanie wewnętrznych identyfikatorów org_id i provider_id poprzez endpoint /private/sso/check-domain. Pozwala to na mapowanie domen email na identyfikatory UUID organizacji i dostawców SSO, co ułatwia rozpoznanie infrastruktury.

Podatność w Capgo przed wersją 12.128.2 umożliwia administratorom przedsiębiorstwa usuwanie tożsamości haseł użytkowników z innych organizacji poprzez endpoint SSO prelink. Atakujący z uprawnieniami org.update_settings i aktywnym dostawcą SSO mogą trwale usunąć uwierzytelnianie e-mailowe dla dowolnego użytkownika pasującego do domeny e-mail dostawcy.

Podatność w Capgo przed wersją 12.128.2 umożliwia zmianę adresu e-mail konta bez wymagania ponownego uwierzytelnienia bieżącym hasłem lub weryfikacji istniejącego adresu e-mail. Atakujący posiadający ważny plik cookie sesji lub uwierzytelnioną przeglądarkę może zmienić adres e-mail konta, przejmując kontrolę nad odzyskiwaniem konta i omijając ochronę uwierzytelniania wieloskładnikowego.

Capgo przed wersją 12.128.2 zawiera podatność na wstrzykiwanie SQL w punkcie końcowym POST /private/admin_stats. Parametr limit jest pobierany z niezweryfikowanego ciała żądania i bezpośrednio interpolowany do zapytań SQL silnika Cloudflare Analytics Engine za pomocą literałów szablonów.

Podatność w Capgo przed wersją 12.128.2 w punkcie końcowym POST /webhooks/test umożliwia kluczom API o zakresie aplikacji wywoływanie operacji webhooków na poziomie organizacji. Atakujący z poświadczeniami ograniczonymi do aplikacji mogą wysyłać podpisane żądania webhooków do dowolnych webhooków organizacji, omijając kontrolę autoryzacji limited_to_apps.

W Capgo przed wersją 12.128.2 występuje luka w eskalacji uprawnień, gdzie zdegradowani użytkownicy super_admin zachowują dostęp do RPC delete_non_compliant_bundles i count_non_compliant_bundles z powodu nieczyszczenia kolumny org_users.user_right podczas usuwania powiązania roli. Atakujący mogą wykorzystać to, utrzymując wcześniej przyznaną rolę super_admin, aby bezterminowo wyliczać i masowo usuwać niezgodne pakiety w całej organizacji.

Podatność w Capgo przed wersją 12.128.2 umożliwia nieuwierzytelnionym atakującym odczyt wrażliwych danych finansowych i operacyjnych poprzez endpoint global_stats Supabase PostgREST. Wykorzystując jedynie publiczny klucz API, można pobrać dane takie jak MRR, całkowity przychód, podział przychodów według planów taryfowych, liczbę klientów oraz telemetrię operacyjną.

Capgo przed wersją 12.128.2 zawiera lukę ujawnienia informacji w funkcji PostgreSQL find_apikey_by_value, która jest oznaczona jako SECURITY DEFINER i wykonywalna przez rolę anon. Nieuwierzytelnieni atakujący mogą wywołać tę funkcję przez endpoint /rest/v1/rpc/find_apikey_by_value, aby pobrać wrażliwe metadane klucza API, w tym user_id, tryb, zakres organizacyjny i szczegóły wygaśnięcia, po podaniu prawidłowej wartości klucza.

Podatność w Capgo przed wersją 12.128.12 umożliwia ominięcie autoryzacji rozliczeniowej poprzez rozbieżność w obliczeniach plan_valid. Organizacje z wyczerpanymi lub przedawnionymi kredytami mogą nadal korzystać z endpointów /updates, /stats, /channel_self oraz przesyłania załączników.

Podatność w Capgo przed wersją 12.128.2 umożliwia ominięcie autoryzacji, gdzie klucze API z zakresem zapisu mogą bezpośrednio modyfikować chronione pola konfiguracji kanałów przez PostgREST, wykorzystując brak sprawdzania uwierzytelnienia w wyzwalaczu niezmienności. Atakujący z kluczami API do zapisu mogą zmieniać wrażliwe atrybuty kanałów, takie jak public, allow_emulator i flagi związane z bezpieczeństwem, poza zamierzonymi ścieżkami aplikacji.

Podatność w Capgo przed wersją 12.128.2 w punkcie końcowym accept_invitation powoduje, że konta użytkowników są tworzone przed weryfikacją captcha. Atakujący mogą ominąć ochronę captcha, wysyłając żądania POST z nieprawidłowymi tokenami captcha, co umożliwia tworzenie niechcianych kont i wypalanie linków zaproszeń.

Podatność w Capgo przed wersją 12.128.2 nie egzekwuje ograniczeń planu/kwoty na endpointcie /files/upload/attachments, co pozwala aplikacjom zablokowanym przez plan na tworzenie publicznie czytelnych obiektów R2. Atakujący mogą przesyłać dowolne załączniki przy użyciu kluczy API z zakresem upload, które omijają sprawdzanie planu, utrzymują się poza normalnymi metadanymi pakietu i przetrwają usunięcie aplikacji, umożliwiając nadużycie pamięci i przepustowości.

Podatność w Capgo przed wersją 12.128.2 umożliwia ominięcie uwierzytelniania w punkcie końcowym zmiany hasła. Atakujący mogą zmienić hasło użytkownika bez potwierdzenia bieżącego hasła.

Podatność w Capgo przed wersją 12.128.2 polega na braku usuwania metadanych EXIF z obrazów przesyłanych przez endpoint informacji o aplikacji. Umożliwia to atakującym wyodrębnienie danych geolokalizacyjnych i innych metadanych z przesłanych plików.

Podatność w Capgo przed wersją 12.128.2 ujawnia informacje poprzez funkcję RPC Supabase PostgREST public.get_total_metrics(org_id), która jest dostępna dla roli anon przy użyciu publicznego klucza sb_publishable_*. Nieuwierzytelniony atakujący może sprawdzać istnienie organizacji i wyciekać poufne dane, takie jak MAU, przepustowość i liczba instalacji, wysyłając żądania POST do /rest/v1/rpc/get_total_metrics z prawidłowymi UUID organizacji.

Podatność HTML injection w Capgo przed wersją 12.128.2 w punkcie końcowym ustawień organizacji umożliwia atakującym wstrzyknięcie złośliwego kodu HTML. Poprzez pole nazwy organizacji mogą oni przekierowywać użytkowników na niebezpieczne strony, co prowadzi do ataków phishingowych i szkód w reputacji.

Podatność w Capgo przed wersją 12.128.2 umożliwia nieuwierzytelnionym atakującym dostęp do wrażliwych danych organizacyjnych użytkowników poprzez funkcję RPC public.get_orgs_v6. Funkcja ta, zdefiniowana jako SECURITY DEFINER i przypisana do roli anon, nie weryfikuje zgodności identyfikatora UUID użytkownika z uwierzytelnionym kontekstem.

Podatność w Capgo przed wersją 12.128.2 umożliwia ominięcie autoryzacji w polityce INSERT dla public.manifest, co pozwala członkom organizacji z dostępem tylko do odczytu na wstawianie wierszy manifestu OTA. Atakujący z takim dostępem mogą wstrzykiwać złośliwe wpisy manifestu z dowolnymi wartościami s3_path, które są dostarczane do urządzeń przez nieuwierzytelniony endpoint /updates, prowadząc do zatrucia metadanych OTA i potencjalnego dostarczenia złośliwych zasobów.

Podatność w Capgo przed wersją 12.128.2 umożliwia ominięcie polityki szyfrowania pakietów. Atakujący z kluczem API o zakresie aplikacji może zaktualizować tabelę app_versions, usuwając pola session_key i key_id, co pozwala na zastąpienie zaszyfrowanych pakietów nieszyfrowanymi.