Podatności Plane

Podatność w Plane przed wersją 1.4.0 dotyczy braku sanityzacji niebezpiecznych schematów URL w komentarzach (comment_html). Członek projektu może umieścić złośliwy link w komentarzu, a skrypt atakującego wykona się w przeglądarce innego użytkownika, który kliknie link. Problem naprawiono w wersji 1.4.0.

W Plane przed wersją 1.4.0 oprogramowanie pośredniczące aPITokenLogMiddleware loguje klucze API w postaci jawnej. Umożliwia to osobie z niskimi uprawnieniami kradzież kluczy API użytkowników i dalszą eskalację uprawnień.

Plane przed wersją 1.4.0 w manifestach deployments/aio/community/ i deployments/cli/community/ zawiera stałe, publicznie znane domyślne wartości SECRET_KEY i LIVE_SERVER_SECRET_KEY, które pozostają aktywne, gdy operatorzy ich nie nadpiszą. Znajomość SECRET_KEY umożliwia atakującym fałszowanie podpisanych przez Django wartości i kompromitację kont lub sesji. Znajomość LIVE_SERVER_SECRET_KEY omija uwierzytelnianie usługi live na niezmienionych wdrożeniach community.

Plane przed wersją 1.4.0 ufa adresom e-mail zwracanym przez Gitea OAuth oraz przez samodzielnie zarządzane wdrożenia GitLab OAuth, gdzie potwierdzenie e-maila jest wyłączone, bez weryfikacji, czy dostawca uwierzytelnił własność adresu. Atakujący może ustawić niezweryfikowany e-mail dostawcy na adres ofiary, który Plane dopasowuje bezpośrednio do istniejącego lokalnego konta ofiary. Atakujący może następnie zalogować się na konto ofiary bez znajomości hasła. GitHub, GitLab.com i Google nie są dotknięte, ponieważ zwracają zweryfikowane adresy e-mail.

Plane przed wersją 1.4.0 w procesie rejestracji tworzy zalogowany wiersz User dla każdego przesłanego e-maila bez weryfikacji własności poza pasmem, podczas gdy User.email jest unique=True. Uwierzytelniony użytkownik może wywołać GET /api/users/me/workspaces/invitations/, który zwraca każdą WorkspaceMemberInvite, której e-mail pasuje do request.user.email. WorkSpaceMemberInviteSerializer używa fields = "all", ujawniając token chroniący endpoint dołączania do zaproszenia. Nieuwierzytelniony atakujący znający e-mail ofiary może zarejestrować konto z tym adresem, wyliczyć oczekujące zaproszenia i zaakceptować zaproszenie jako ofiara, dołączając do workspace na zaproszonej roli.

Plane przed wersją 1.4.0 w logowaniu przez kod magiczny używa sześciocyfrowego OTP z około 20 bitami entropii. Weryfikator nie ma licznika nieudanych prób na kod, a błędny kod nie zwiększa licznika, nie unieważnia wpisu Redis ani nie blokuje adresu e-mail. Weryfikator rozszerza django.views.View zamiast DRF APIView, więc limit AnonRateThrottle nie ma zastosowania. Stos middleware nie zawiera również ogranicznika szybkości na poziomie Django, takiego jak django-ratelimit, django-axes lub IP-throttling.

Przed wersją 1.4.0 narzędzia Plane, endpoint ProjectBulkAssetEndpoint.post nie ograniczał zapytań o zasoby do projektu z URL-a. Gość z rolą Workspace Guest mógł podać identyfikatory UUID zasobów z innego projektu w tym samym workspace i przypisać je do encji kontrolowanej przez atakującego, co umożliwiało przejęcie plików.

Przed wersją 1.4.0 narzędzia Plane, zadanie dostarczania webhooków nie ustawiało allow_redirects=False i nie walidowało celów przekierowań. Użytkownik z możliwością tworzenia workspace mógł zarejestrować webhook wskazujący na publiczny endpoint kontrolowany przez atakującego, który zwraca przekierowanie 302 do wewnętrznego adresu, co pozwalało na dostęp do wewnętrznych zasobów, w tym metadanych chmury.

Plane, narzędzie do zarządzania projektami open source, w wersji 1.3.1 i wcześniejszych w punkcie końcowym /api/public/assets/v2/anchor/{anchor}/ wymaga uwierzytelnienia do operacji zapisu, ale nie weryfikuje członkostwa w przestrzeni roboczej ani projekcie. Uwierzytelniony użytkownik znający publiczny DeployBoard.anchor opublikowanego projektu może tworzyć rekordy FileAsset w tym projekcie i miękko usuwać istniejące zasoby, co umożliwia wstrzyknięcie plików między przestrzeniami roboczymi, nadużycie pamięci i utratę danych.

W Plane w wersji 1.3.1 i wcześniejszych kontrola autoryzacji w ProjectMemberViewSet.partial_update znajduje się wewnątrz gałęzi aktualizacji roli, więc gość lub członek może pominąć pole role i zmienić pole is_active innego rekordu ProjectMember, w tym dezaktywować administratora projektu. Dodatkowo ProjectMemberPreferenceEndpoint.patch ufa wartości member_id ze ścieżki URL i pozwala członkowi projektu nadpisać preferencje innego członka. Luka została naprawiona w wersji 1.4.0.

W Plane przed wersją 1.4.0 endpoint PageVersionEndpoint w apps/api/plane/app/views/page/version.py zawęża wyszukiwanie wersji stron po identyfikatorach workspace i page, ale nie po project_id z URL. ProjectPagePermission również wyznacza rolę wywołującego na podstawie projektu z URL, jednocześnie rozwiązując żądaną stronę w całym workspace, więc członek jednego projektu może użyć identyfikatora tego projektu, aby odczytać description_html publicznej strony w innym projekcie w tym samym workspace. Ścieżka jest tylko do odczytu i nie umożliwia modyfikacji stron między projektami. Problem naprawiono w wersji 1.4.0.

W Plane przed wersją 1.4.0 wiele punktów końcowych listy zgłoszeń, w tym nieuwierzytelnione publiczne tablice, przekazuje kontrolowany przez użytkownika parametr order_by do Django order_by bez walidacji allowlisty. Atakujący może użyć podwójnego podkreślenia do przechodzenia przez relacje i odwoływania się do dowolnych pól powiązanych modeli, ujawniając szczegóły schematu bazy danych poprzez błędy i potencjalnie ujawniając wartości pól poprzez różnicowe sortowanie. Luka naprawiona w wersji 1.4.0.

W samodzielnie hostowanych wdrożeniach Plane przed wersją 1.4.0 nieuwierzytelnione żądania GET do api/workspaces/{slug}/invitations/{pk}/join/ przez WorkspaceJoinEndpoint ujawniają tajny token zaproszenia bezpośrednio i poprzez get_invite_link. Zewnętrzny atakujący może pobrać token przeznaczony dla innego użytkownika i przesłać go do procesu akceptacji zaproszenia, dołączając do przestrzeni roboczej bez otrzymania zaproszenia i uzyskując przypisaną do niego rolę. Luka naprawiona w wersji 1.4.0.

Plane to narzędzie do zarządzania projektami o otwartym kodzie źródłowym. Przed wersją 1.4.0 endpoint ProjectJoinEndpoint w GET /api/workspaces/{slug}/projects/{project_id}/join/{pk}/ używa permission_classes = [AllowAny] i zwraca pełny rekord ProjectMemberInvite, w tym adres e-mail, token i rolę, nieuwierzytelnionym wywołującym. Odpowiadający endpoint POST sprawdza tylko, czy przesłany e-mail zgadza się z project_invite.email i nie weryfikuje tokena zaproszenia. Atakujący, który zna UUID zaproszenia, może odkryć zaproszony e-mail, zarejestrować konto z tym adresem i zaakceptować zaproszenie bez otrzymania oryginalnego zaproszenia. Problem został naprawiony w wersji 1.4.0.

Plane to narzędzie do zarządzania projektami o otwartym kodzie źródłowym. Przed wersją 1.3.0 metoda ProjectMemberViewSet.partial_update pozwala każdemu członkowi projektu, w tym użytkownikowi z najniższą rolą GUEST, na modyfikację roli innego członka projektu. Kontrola autoryzacji zapobiega przypisaniu roli wyższej niż rola żądającego, ale nie zapobiega przypisaniu roli niższej lub równej, co pozwala Gościowi zdegradować Administratorów i Członków oraz pozbawić ich kontroli nad projektem. Podatność została naprawiona w wersji 1.3.0.

W Plane przed wersją 1.4.0 endpoint PATCH dla załączników zgłoszeń V2 przyjmuje issue_id w adresie URL, ale pomija go w zapytaniu do bazy danych. Członek projektu może podać własny issue_id w URL, a mimo to zmodyfikować załącznik innego użytkownika, dopasowując go po UUID (pk). Gdy załącznik jest w stanie oczekującym, procedura PATCH ustawia created_by na atakującego i przenosi własność załącznika.

W Plane przed wersją 1.4.0 mutacja GraphQL joinProject pozwala dowolnemu członkowi przestrzeni roboczej dodać się do dowolnego projektu w tej przestrzeni, w tym do projektów oznaczonych jako sieć=0 (tajne/prywatne), do których nie został zaproszony, i przyznaje mu pełną rolę Member (odczyt i zapis). Resolver sprawdza tylko członkostwo i rolę na poziomie przestrzeni roboczej, nigdy nie weryfikuje widoczności (network) docelowego projektu. Prowadzi to do zniesienia izolacji projektów w ramach przestrzeni roboczej.

W Plane przed wersją 1.4.0 endpointy WorkspaceFileAssetEndpoint.get i WorkspaceAssetDownloadEndpoint.get rozwiązują rekordy FileAsset w przestrzeni roboczej bez sprawdzania członkostwa w projekcie zasobu, co pozwala członkowi przestrzeni pobierać zasoby z prywatnych projektów, jeśli zna UUID zasobu. EntityAssetEndpoint.get to osobny publiczny endpoint z dostępem AllowAny, który ogranicza wyszukiwanie tylko do przestrzeni roboczej kotwicy, a nie do jej opublikowanej encji lub projektu. Nieuwierzytelniony wywołujący znający prawidłową kotwicę i UUID zasobu może pobrać zasoby opisów zgłoszeń lub komentarzy należące do nieopublikowanych lub prywatnych projektów w tej przestrzeni.

W Plane przed wersją 1.4.0 uwierzytelniony członek przestrzeni roboczej o niskich uprawnieniach, w tym Gość, może przesłać plik image/svg+xml jako załącznik ogólny lub do zgłoszenia. Plik zachowuje kontrolowany przez atakującego nagłówek Content-Type, a endpoint pobierania zasobów tworzy presigned URL z Content-Disposition: inline. W domyślnym wdrożeniu self-hosted MinIO adres URL zasobu jest serwowany z tej samej domeny co aplikacja Plane, co pozwala na wykonanie osadzonego JavaScriptu SVG w kontekście bezpieczeństwa aplikacji. Ofiara, w tym administrator przestrzeni roboczej, otwierając link, może mieć przejętą sesję poprzez stored XSS, co prowadzi do przejęcia konta.

W Plane przed wersją 1.4.0 BulkEstimatePointEndpoint.destroy rozwiązuje punkt estymacji poprzez bezpośrednie wyszukiwanie po kluczu głównym, bez ograniczenia do przestrzeni roboczej, projektu lub estymacji. Administrator lub członek jednej przestrzeni roboczej może trwale usunąć punkt estymacji należący do innej przestrzeni, podając docelowy UUID w adresie URL w ramach własnej przestrzeni. Tworzy to destrukcyjny cross-tenant IDOR.

W Plane przed wersją 1.4.0 proces synchronizacji awatarów OAuth pobiera avatar_url z danych użytkownika dostawcy poprzez żądanie HTTP po stronie serwera bez walidacji wewnętrznych adresów IP i domyślnie podąża za przekierowaniami. Atakujący może podać adres URL awatara, który przekierowuje do zasobu wewnętrznego, takiego jak endpoint metadanych, a Plane przesyła pobraną odpowiedź jako plik awatara użytkownika. Obiekt jest następnie udostępniany przez /api/assets/v2/static/{asset_id}/, co pozwala na eksfiltrację wewnętrznie pobranej treści.

W Plane (open-source narzędzie do zarządzania projektami) w wersjach przed 1.4.0 występuje podatność XSS. IntakeIssuePublicViewSet.create w wersji 1.3.1 zapisuje description_html bez walidacji przy użyciu validate_html_content z nh3. Uwierzytelniony użytkownik może umieścić dowolny HTML w projekcie z opublikowanym DeployBoard i włączonym intake, a po kliknięciu przez ofiarę następuje wykonanie JavaScriptu i kradzież tokenu API.

W Plane (open-source narzędzie do zarządzania projektami) w wersjach przed 1.4.0 endpoint listy zaproszeń projektowych jest dostępny dla każdego uwierzytelnionego użytkownika znającego slug workspace i ID projektu. Publiczny endpoint akceptacji zaproszenia przyjmuje zaproszenie na podstawie podanego adresu e-mail. Atakujący może wyliczyć zaproszenie, zarejestrować konto na zaproszony e-mail bez weryfikacji skrzynki i zaakceptować zaproszenie, dodając swoje konto do workspace i projektu.

W Plane (open-source narzędzie do zarządzania projektami) w wersjach przed 1.4.0 poprawka dla CVE-2026-27706 i GHSA-jcc6-f9v6-f7jw dotycząca SSRF w odwijaniu linków do elementów pracy jest niekompletna w wersji 1.3.1 GA. Każdy uwierzytelniony członek projektu może zmusić serwer do pobrania wybranych wewnętrznych celów, w tym metadanych chmury pod 169.254.169.254, i odczytać treść odpowiedzi jako tytuł linku lub faviconę.

W Plane (open-source narzędzie do zarządzania projektami) w wersjach przed 1.4.0 walidacja GITEA_HOST sprawdza tylko schemat URL i nie odrzuca hostów rozwiązujących się na prywatne lub wewnętrzne adresy IP. Cztery żądania wychodzące w przepływie OAuth Gitea są tworzone na podstawie tego niezwalidowanego hosta i nie wywołują validate_url(). Dodatkowo avatar_url pochodzi z profilu użytkownika Gitea, gdzie można ustawić zewnętrzne adresy URL. Po włączeniu OAuth Gitea przez administratora, użytkownik Gitea może ustawić wewnętrzny URL jako avatar i zalogować się przez Gitea, powodując pobranie wewnętrznego celu bez walidacji.

W Plane (open-source narzędzie do zarządzania projektami) w wersjach przed 1.4.0 endpointy zasobów dashboardu w plane/app/views/asset/v2.py zostały naprawione pod kątem dwóch cross-tenant IDOR (CVE-2026-27705 i CVE-2026-46558), ale aplikacja Spaces w plane/space/views/asset.py obsługująca operacje publicznych tablic pod /api/public/ nie została naprawiona. EntityAssetEndpoint i AssetRestoreEndpoint rozwiązują DeployBoard z publicznego anchora, a następnie odczytują lub modyfikują wiersze FileAsset w zakresie tylko workspace tablicy, bez sprawdzania członkostwa i ograniczenia project_id. Atakujący może odczytywać, nadpisywać lub przywracać zasoby między projektami i workspace'ami.

W Plane (open-source narzędzie do zarządzania projektami) w wersjach przed 1.4.0 użytkownik, którego konto zostało dezaktywowane przez ustawienie is_active=False, może nadal zalogować się przy użyciu istniejących poświadczeń. Udana autoryzacja po cichu zmienia is_active z powrotem na True, reaktywując konto bez powiadamiania administratora.

W Plane (open-source narzędzie do zarządzania projektami) w wersjach przed 1.4.0 poprawka dla CVE-2026-30242 waliduje adresy IP webhooków tylko przy tworzeniu webhooka w apps/api/plane/app/serializers/webhook.py. Zadanie dostarczania w apps/api/plane/bgtasks/webhook_task.py wykonuje osobną resolucję DNS przy wysyłaniu żądania i nie waliduje rozwiązanego adresu IP, co pozwala na DNS rebinding i obejście ochrony SSRF.

W Plane (open-source narzędzie do zarządzania projektami) w wersjach przed 1.4.0 DuplicateAssetEndpoint pobiera źródłowy FileAsset bez ograniczenia do workspace wywołującego, co pozwala na duplikację zasobów między workspace'ami. WorkspaceFileAssetEndpoint i legacy FileAssetEndpoint pomijają autoryzację workspace, umożliwiając uwierzytelnionym użytkownikom odczyt, tworzenie, modyfikację lub usuwanie zasobów w workspace'ach, których nie są członkami. Dodatkowo WorkspaceViewViewSet.retrieve nie ma dekoratora autoryzacji używanego przez inne akcje, co odsłania nieautoryzowany odczyt widoków workspace.

W narzędziu Plane (wersje od 0.13 do 1.4.0) endpoint InstanceAdminSignUpEndpoint używa InstanceAdmin.objects.first() do sprawdzenia pierwszego administratora i tworzy konto bez transakcji atomowej, blokady wiersza czy zabezpieczenia unikalności. Dwa równoczesne nieuwierzytelnione żądania z różnymi adresami e-mail mogą oba uznać, że nie istnieje administrator instancji, utworzyć osobne konta i otrzymać sesje z uprawnieniami administratora instancji.

Plane to narzędzie do zarządzania projektami typu open-source. Przed wersją 1.4.0 endpoint cykli przyjmuje UUID problemów w treści żądania bez walidacji, czy należą one do przestrzeni roboczej wywołującego. Uwierzytelniony użytkownik może dodać problemy z dowolnej przestrzeni roboczej do cyklu, który kontroluje. Jeśli problem ofiary jest już przypisany do cyklu, operacja usuwa go z cyklu ofiary, powodując destrukcyjny zapis między dzierżawcami. Problem naprawiono w wersji 1.4.0.

W Plane przed wersją 1.4.0 endpoint GET /api/workspaces/{slug}/entity-search/?query_type=user_mention zwraca nazwy wyświetlane, UUID i adresy URL awatarów członków workspace każdemu uwierzytelnionemu użytkownikowi znającemu slug workspace, nawet jeśli nie jest członkiem. Endpoint ujawnia również wiersze ProjectMember w tej samej sytuacji, ponieważ SearchEndpoint dziedziczy BaseAPIView tylko z permission_classes = [IsAuthenticated] i nie sprawdza członkostwa w workspace.

Plane to narzędzie do zarządzania projektami typu open-source. Przed wersją 1.4.0 endpointy BulkDeleteIssuesEndpoint i SubIssuesEndpoint w apps/api/plane/app/views/issue/ przyjmują identyfikatory problemów z treści żądania lub URL i operują na nich bez sprawdzania, czy należą do przestrzeni roboczej i projektu wywołującego. Dekorator uprawnień na każdym endpointcie sprawdza tylko, czy wywołujący jest członkiem lub administratorem przestrzeni roboczej i projektu wymienionych w URL. BulkDeleteIssuesEndpoint może zniszczyć asocjacje CycleIssue i ModuleIssue należące do obcych problemów. SubIssuesEndpoint może przenieść obce problemy pod wybrany przez atakującego problem i zwrócić metadane obcych problemów. Problem naprawiono w wersji 1.4.0.

W Plane przed wersją 1.4.0 dwie rodziny endpointów nie weryfikują, czy zagnieżdżone identyfikatory zasobów należą do workspace i projektu wskazanych w URL. Uwierzytelniony użytkownik może odczytywać lub modyfikować szacunki z innego workspace przez PATCH /api/workspaces/{slug}/projects/{project_id}/estimates/{estimate_id}/ oraz wstrzykiwać komentarze do zgłoszenia z innego workspace przez POST /api/workspaces/{slug}/projects/{project_id}/issues/{issue_id}/comments/. ProjectEntityPermission sprawdza członkostwo w workspace i projekcie z URL, ale estimate_id i issue_id są pobierane po kluczu głównym bez potwierdzenia tego samego zakresu.

Plane to narzędzie do zarządzania projektami typu open-source. Przed wersją 1.4.0 endpoint relacji problemów przyjmuje UUID problemów w treści żądania bez walidacji, czy należą one do przestrzeni roboczej wywołującego. Uwierzytelniony użytkownik może tworzyć relacje łączące jego własne problemy z problemami w dowolnej innej przestrzeni roboczej, co prowadzi do wycieku metadanych problemów przez zdarzenia aktywności. Problem naprawiono w wersji 1.4.0.

Plane to narzędzie do zarządzania projektami typu open-source. Przed wersją 1.4.0 endpoint aktualizacji projektu autoryzuje wywołującego na podstawie sluga przestrzeni roboczej w URL, ale ładuje docelowy projekt globalnie po UUID bez powiązania z tą przestrzenią roboczą. Administrator jednej przestrzeni roboczej może modyfikować projekt w innej przestrzeni roboczej, jeśli zna UUID projektu ofiary. Narusza to izolację dzierżawców i pozwala na nieautoryzowane zmiany metadanych i konfiguracji projektu między przestrzeniami roboczymi. Problem naprawiono w wersji 1.4.0.

Plane to narzędzie do zarządzania projektami typu open-source. Przed wersją 1.4.0 endpointy GET /api/workspaces/{slug}/cycles/ (WorkspaceCyclesEndpoint) i GET /api/workspaces/{slug}/modules/ (WorkspaceModulesEndpoint) zwracają rekordy ze wszystkich projektów w przestrzeni roboczej bez sprawdzania, czy wywołujący należy do każdego projektu. Każdy uwierzytelniony członek przestrzeni roboczej, w tym Gość z dostępem tylko do jednego projektu, może wyliczyć nazwy, opisy, daty sprintów, liczby problemów, migawki postępu, zewnętrzne identyfikatory integracji, powiązane URL-e i listy członków dla cykli i modułów w prywatnych projektach. Sąsiednie endpointy WorkspaceLabelsEndpoint i WorkspaceStatesEndpoint stosują odpowiedni filtr, co czyni endpointy cykli i modułów niespójnymi. Problem naprawiono w wersji 1.4.0.

Przed wersją 1.4.0 narzędzia Plane, endpoint GET /api/v1/workspaces/{slug}/projects/{project_id}/members/ ujawnia pełną listę członków projektu, w tym adresy e-mail, imiona i nazwiska, awatary i role. Kontrola dostępu ProjectMemberPermission sprawdza tylko, czy użytkownik jest aktywnym członkiem dowolnego projektu w workspace, ale nie wiąże tego z konkretnym project_id. W rezultacie każdy uwierzytelniony użytkownik należący do jednego projektu, w tym Gość, może odczytać listę członków innego prywatnego projektu w tym samym workspace.

Przed wersją 1.4.0 narzędzia Plane, uprawnienie WorkspaceOwnerPermission nie wymaga, aby użytkownik miał ustawione is_active=True podczas sprawdzania, czy jest właścicielem workspace. Dezaktywowany użytkownik może pozostać autoryzowany jako właściciel workspace i zachować dostęp na poziomie właściciela.

Przed wersją 1.4.0 narzędzia Plane, endpoint GET /api/assets/v2/workspaces/{workspace_slug}/download/{asset_id}/ umożliwia pobieranie plików przypisanych do projektów bez sprawdzania dostępu do projektu, do którego należą. Uwierzytelniony użytkownik z tego samego workspace, niebędący członkiem tajnego projektu, znając UUID zasobu, może otrzymać przekierowanie 302 do podpisanego URL-a pobierania. Dotyczy to typów ISSUE_ATTACHMENT, COMMENT_DESCRIPTION, PAGE_DESCRIPTION i PROJECT_COVER.

Przed wersją 1.4.0 narzędzia Plane, nieuwierzytelniony endpoint publicznych zgłoszeń przyjmuje parametry group_by i sub_group_by bez listy dozwolonych wartości i przekazuje je do paginatorów, gdzie są używane jako nazwy pól ORM. Atakujący może podać dowolne ścieżki pól, co powoduje nieobsłużone błędy FieldError lub KeyError i odpowiedź HTTP 500, lub może wykorzystać to jako wyrocznię do ślepej eksploracji relacyjnych ścieżek. Poprawka z wcześniejszej wersji nie objęła tych parametrów.

Przed wersją 1.4.0 narzędzia Plane, członek projektu z rolą 15 może wysłać żądanie PATCH do endpointu aktualizacji członków projektu i zmienić rolę innego użytkownika. Logika aktualizacji roli blokuje tylko nową rolę wyższą niż rola żądającego, więc przypisanie równej roli Member omija walidację i awansuje Gościa projektu z rolą 5 do roli Member bez zgody administratora projektu.

Przed wersją 1.4.0 narzędzia Plane, endpoint modułów przyjmuje identyfikatory UUID zgłoszeń w ścieżce URL bez walidacji, czy należą one do workspace wywołującego. Uwierzytelniony użytkownik może linkować zgłoszenia z dowolnego workspace do modułów w swoim własnym workspace.

Przed wersją 1.4.0 narzędzia Plane, endpoint GET /api/users/api-tokens/ pozwala uwierzytelnionemu użytkownikowi pobierać rekordy tokenów API, a PATCH /api/users/api-tokens/{token_id}/ pozwala modyfikować pole allowed_rate_limit bez walidacji po stronie serwera. Użytkownik może dowolnie podnieść limit i ominąć limity API, co umożliwia wysoką liczbę automatycznych żądań i potencjalne wyczerpanie zasobów.

Plane do wersji 1.4.2 nie sprawdza, czy zgłoszenia (issues) należą do projektu tablicy wdrożeniowej w publicznym endpointcie komentarzy. Uwierzytelnieni atakujący mogą dodawać komentarze do dowolnych zgłoszeń w różnych przestrzeniach roboczych, podając parametr issue_id w publicznym endpointcie komentarzy tablicy wdrożeniowej.

Podatność w Plane polegająca na wadzie autoryzacji w API zarządzania zasobami. Uwierzytelnieni użytkownicy mogą uzyskać dostęp, usunąć lub skopiować zasoby (assets) należące do innego workspace, podając tylko slug i ID zasobu ofiary. Brak weryfikacji członkostwa w docelowym workspace umożliwia cross-tenantową ekspozycję danych, ich usunięcie oraz trwałe wyeksfiltrowanie plików do workspace atakującego.

Plane to narzędzie do zarządzania projektami typu open-source. Przed wersją 1.3.1 występowała luka umożliwiająca obejście autoryzacji zasobów między przestrzeniami roboczymi, co pozwalało każdemu uwierzytelnionemu użytkownikowi na odczyt, kopiowanie, usuwanie i nadpisywanie zasobów w innych przestrzeniach roboczych Plane.

W Plane (narzędzie do zarządzania projektami) w wersjach 1.3.0 i starszych, endpoint SavedAnalyticEndpoint przekazuje kontrolowany przez użytkownika parametr segment bezpośrednio do wyrażenia Django F() bez walidacji, co powoduje wstrzyknięcie referencji do pól ORM. Uwierzytelniony członek workspace może odczytać wrażliwe dane, takie jak hashe haseł bcrypt, tokeny API i adresy e-mail.

Plane przed wersją 1.3.0 zawiera podatność w przepływie uwierzytelniania, gdzie adres e-mail użytkownika jest dołączany jako parametr zapytania w URL podczas obsługi błędów (np. gdy zostanie przesłany nieprawidłowy kod magiczny). Przekazywanie danych osobowych (PII) za pomocą ciągów zapytania w żądaniach GET jest uznawane za niebezpieczną praktykę projektową. Kod znajduje się w module narzędzi uwierzytelniania (packages/utils/src/auth.ts).

Plane, otwartoźródłowe narzędzie do zarządzania projektami, zawiera lukę w punkcie końcowym IssueBulkUpdateDateEndpoint. Umożliwia ona członkowi projektu (ADMIN lub MEMBER) modyfikację dat startu i celu dowolnego zgłoszenia w całej instancji Plane, niezależnie od przynależności do obszaru roboczego lub projektu. Luka występuje przed wersją 1.3.0.