CVE-2026-104966
WysokieCVSS 8.7Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 15 - wyżej niż 15% wszystkich znanych CVE
Streszczenie
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.
Ocena ryzyka
Uwierzytelniony użytkownik może modyfikować dane w workspace, do których nie należy, naruszając integralność i poufność danych innych zespołów. Może to prowadzić do nieautoryzowanych zmian w szacunkach i wstrzykiwania treści do zgłoszeń.
Rekomendacja
Zaktualizować Plane do wersji 1.4.0. Do czasu aktualizacji zweryfikować, czy endpointy poprawnie ograniczają zapytania do właściwego workspace i projektu.
Inne podatności w Plane
Zobacz wszystkie- CVE-2026-102982Wysokie
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.
- CVE-2026-104892Wysokie
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ń.
- CVE-2026-105641Krytyczne
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.
- CVE-2026-105640Krytyczne
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.
- CVE-2026-105639Krytyczne
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.
- CVE-2026-105638Krytyczne
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.
- CVE-2026-105637Krytyczne
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.
- CVE-2026-105636Krytyczne
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.
- CVE-2026-102986Wysokie
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.
- CVE-2026-102985Średnie
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.
Oryginalny opis (angielski, źródło NVD)
Plane is an open-source project management tool. Prior to 1.4.0, two endpoint families fail to verify that nested resource identifiers belong to the workspace and project named in the URL. An authenticated user can read or modify estimates from another workspace through PATCH /api/workspaces/{slug}/projects/{project_id}/estimates/{estimate_id}/, and can inject comments into an issue from another workspace through POST /api/workspaces/{slug}/projects/{project_id}/issues/{issue_id}/comments/. ProjectEntityPermission verifies membership in the workspace and project from the URL, but estimate_id and issue_id are fetched by primary key without confirming the same scope. The list, retrieve, and destroy handlers correctly scope their queries, demonstrating the inconsistency. This issue is fixed in 1.4.0.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS