CVE-2025-69284

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