CVE-2026-104893

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.

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

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.