CVE-2026-100611
ŚrednieCVSS 6.5Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 11 - wyżej niż 11% wszystkich znanych CVE
Streszczenie
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.
Ocena ryzyka
apikey_manager, który nie może przesyłać bundle ani promować kanałów, może utworzyć klucz API powiązany z rolą wdrożeniową i użyć go do wypychania dowolnych aktualizacji JavaScript OTA do wszystkich użytkowników aplikacji organizacji. Może to prowadzić do wykonania złośliwego kodu na urządzeniach końcowych.
Rekomendacja
Brak dostępnej poprawki — monitoruj komunikaty producenta i wdróż ją, gdy tylko będzie dostępna. Do czasu aktualizacji rozważ ograniczenie roli apikey_manager i audyt tworzonych kluczy API.
Inne podatności w Capgo
Zobacz wszystkie- CVE-2026-88863Wysokie
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.
- CVE-2026-56329Średnie
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.
- CVE-2026-56279Wysokie
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.
- CVE-2026-56293Średnie
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.
- CVE-2026-56250Wysokie
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.
- CVE-2026-56246Wysokie
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.
- CVE-2026-56322Wysokie
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.
- CVE-2026-56234Średnie
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.
- CVE-2026-88864Krytyczne
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.
- CVE-2026-100629Średnie
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).
Oryginalny opis (angielski, źródło NVD)
Capgo (capgo.app backend, versions ≤ 12.261.0) improperly restricts which roles the apikey_manager organization role may bind to newly created API keys. When an authenticated user holding only apikey_manager (permissions org.manage_apikeys and org.read) calls POST /apikey with a JWT session, the only checks applied are the org.manage_apikeys permission, a fixed deny-list of assignable role names (APIKEY_MANAGER_DENIED_ASSIGNABLE_ROLES in public/apikey/scope.ts), and a priority-rank comparison in createRoleBindingForPrincipal (private/role_bindings.ts). No check verifies that the caller actually holds the permissions conferred by the role being assigned. Because the deny-list omits the deploy roles app_developer, app_uploader, channel_developer and channel_uploader, and apikey_manager is seeded with priority_rank 78 — higher than those roles' ranks (68, 66, 58, 57) — the rank check also passes. As a result, an apikey_manager who cannot upload bundles or promote channels can mint an API key bound to a deploy role and use it to push arbitrary OTA JavaScript updates to all end users of the organization's apps. As of the advisory publication no patched version was available.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS

