CVE-2026-105686

Penpot to platforma do projektowania i prototypowania o otwartym kodzie źródłowym. Przed wersją 2.18.0, RPC get-page akceptuje obiekt uprawnień linku udostępniającego z pełnym dostępem do odczytu, ale nie weryfikuje, czy wybrane przez wywołującego page-id należy do zestawu autoryzowanych stron linku. Atakujący z ważnym linkiem udostępniającym i własną uwierzytelnioną sesją Penpot może pobrać pełne dane kształtów i projektu innej strony w tym samym pliku, jeśli zna jej identyfikator, ponieważ get-page wymaga uwierzytelnienia. Powiązany RPC get-file-fragment również pozwala na dostęp przez link udostępniający bez mapowania fragmentów do autoryzowanych stron. Problem naprawiono w wersji 2.18.0.

Penpot to platforma do projektowania i prototypowania o otwartym kodzie źródłowym. Przed wersją 2.18.0, assemble-chunks pobiera sesję przesyłania tylko na podstawie jej identyfikatora sesji, podczas gdy upload-chunk poprawnie ogranicza wyszukiwanie do uwierzytelnionego profilu. Uwierzytelniony użytkownik, który zdobędzie identyfikator UUID aktywnej, zakończonej sesji przesyłania innego użytkownika, może złożyć fragmenty ofiary do własnego pliku, czcionki zespołu lub importu projektu, ujawniając przesłane bajty i usuwając oczekującą sesję ofiary. Problem naprawiono w wersji 2.18.0.

Penpot to platforma do projektowania i prototypowania o otwartym kodzie źródłowym. Przed wersją 2.18.0, uwierzytelnieni użytkownicy z uprawnieniami do edycji plików mogą przesyłać media SVG, których skrypty, atrybuty obsługi zdarzeń i elementy foreignObject są przechowywane bez sanityzacji i serwowane jako image/svg+xml z pochodzenia Penpot. Ofiara, która przejdzie na adres URL zasobu, wykonuje kontrolowany przez atakującego JavaScript w tym pochodzeniu, co pozwala na żądania i dostęp do danych z uprawnieniami sesji ofiary w Penpot. Problem naprawiono w wersji 2.18.0.

Penpot to platforma do projektowania i prototypowania o otwartym kodzie źródłowym. Przed wersją 2.18.0, nieuwierzytelniony RPC get-view-only-bundle zwraca wszystkie wiersze linków udostępniających dla pliku, nawet gdy wywołujący uwierzytelnił się tylko jednym linkiem o ograniczonym zakresie. Posiadacz restrykcyjnego linku może uzyskać sekretne identyfikatory innych linków, zakresy stron, uprawnienia do komentarzy i uprawnienia do inspekcji, a następnie odtworzyć bardziej permisywny token, aby uzyskać dostęp do danych stron, które nie były uwzględnione w oryginalnym udostępnieniu. Problem naprawiono w wersji 2.18.0.

W Penpot przed wersją 2.18.0 procedura delete-share-link weryfikuje jedynie uprawnienia edycji pliku nadrzędnego, nie sprawdzając, czy wywołujący utworzył dany link ani czy ma uprawnienia właściciela lub administratora. Każdy edytor pliku znający UUID linku udostępniania może usunąć linki utworzone przez innych użytkowników i odebrać dostęp zewnętrznym recenzentom.

W Penpot przed wersją 2.18.0 wylogowanie usuwa jedynie cookie z tokenem uwierzytelniającym w przeglądarce, nie unieważniając odpowiadającej sesji po stronie serwera. Wcześniej przechwycony token sesji pozostaje ważny po wylogowaniu ofiary i pozwala na dalsze uwierzytelnione żądania z jej uprawnieniami aż do naturalnego wygaśnięcia.

W Penpot przed wersją 2.18.0 funkcja app.util.ssrf/blocked-address? opiera się na predykatach Java InetAddress, które nie klasyfikują adresów NAT64, 6to4 ani Teredo, a dodatkowe sprawdzenia CIDR stosuje tylko do adresów IPv4. Użytkownik kontrolujący URL importu mediów lub administrator kontrolujący URL webhooka może podać adres przejściowy IPv6 osadzający docelowy adres IPv4 (metadane chmury, loopback, link-local, prywatny) i obejść ograniczenia SSRF.

W Penpot przed wersją 2.18.0 procedury create-team-invitations oraz ścieżka akceptacji zaproszenia pozwalają administratorowi zespołu niebędącemu właścicielem przypisać rolę właściciela, ponieważ role zaproszeń są zapisywane i stosowane bez sprawdzenia limitu roli używanego w update-team-member-role. Administrator może zaprosić inne konto jako właściciela, utworzyć wielu właścicieli i przejąć kontrolę zarezerwowaną dla właściciela.

W Penpot przed wersją 2.18.0 procedura delete-team-member pozwala administratorowi zespołu usunąć dowolnego członka poza sobą, ale nie chroni właściciela zespołu. Administrator niebędący właścicielem może usunąć członkostwo team-profile-rel właściciela i zablokować mu dostęp do zespołu oraz jego projektów, plików, czcionek i mediów.

W Penpot przed wersją 2.18.0 polecenia RPC get-comment-threads, get-comment-thread i get-comments używają check-comment-permissions!, ale nie stosują ograniczenia stron linku udostępniania. Posiadacz linku udostępniania ograniczonego do strony może pobrać wątki komentarzy i pełne treści komentarzy z innych stron tego samego pliku, w tym nazwiska, adresy e-mail, zdjęcia i identyfikatory stron.