Katalog podatności CVE

Znaleziono błąd w Maestro. Jego punkty końcowe API REST do zapisu zostały zarejestrowane bez odpowiedniego oprogramowania pośredniczącego do uwierzytelniania. Pozwala to zdalnemu atakującemu na wykonywanie nieautoryzowanych operacji zapisu, takich jak tworzenie, modyfikowanie lub usuwanie konsumentów i pakietów zasobów. Może to prowadzić do problemów z integralnością danych lub denial of service (DoS).

W produkcie maestro znaleziono podatność na wstrzykiwanie SQL w parametrze `orderBy` w punktach końcowych listy API REST. Zdalny atakujący bez uwierzytelnienia może wykorzystać tę podatność do ślepego, odczytowego wydobycia danych z bazy danych.

W brokerze gRPC produktu maestro znaleziono podatność umożliwiającą zdalnemu atakującemu z ważnym certyfikatem klienta obejście uwierzytelnienia. Dzięki temu atakujący może subskrybować strumienie zdarzeń innych konsumentów, co prowadzi do nieautoryzowanego ujawnienia informacji, lub publikować sfałszowany status agenta, co może naruszyć integralność danych.

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 procedura chunked media upload sprawdza, czy indeks fragmentu mieści się w zakresie, ale nie odrzuca już zapisanego indeksu ani nie zastępuje poprzedniego obiektu. Uwierzytelniony użytkownik może wielokrotnie przesyłać ten sam prawidłowy indeks, powodując alokację kolejnych obiektów tymczasowych i zwiększenie zajętości pamięci ponad zadeklarowany rozmiar sesji.

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.

Ghost to system zarządzania treścią oparty na Node.js. Od wersji 5.9.0 do 6.44.1 problem z walidacją danych wejściowych pozwalał członkom na dostęp do komentarzy, do których nie mieli uprawnień. Problem naprawiono w wersji 6.44.1.

Ghost to system zarządzania treścią oparty na Node.js. Od wersji 5.81.0 do 6.60.0 pracownicy z rolą Autora mogli usuwać wpisy i strony, których nie byli autorami. Problem naprawiono w wersji 6.60.0.

Ghost to system zarządzania treścią oparty na Node.js. Od wersji 0.5.0 do 6.64.0 pracownicy z rolą Redaktora lub Super Redaktora mogli przypisywać własną rolę użytkownikom z rolą Autora i Współtwórcy, mimo braku uprawnień do przypisywania tej roli. Problem naprawiono w wersji 6.64.0.

Ghost to system zarządzania treścią oparty na Node.js. Od wersji 1.20.0 do 6.64.0 podatność w sposobie ładowania plików tłumaczeń motywów umożliwiała uwierzytelnionemu Administratorowi odczyt plików JSON poza katalogiem aktywnego motywu, potencjalnie ujawniając sekrety konfiguracji serwera. Problem został naprawiony w wersji 6.64.0.

Ghost to system zarządzania treścią oparty na Node.js. Od wersji 6.0.9 do 6.65.0 problem z walidacją umożliwiał nieuwierzytelnionemu użytkownikowi nadużycie niektórych funkcji, takich jak Webmentions, do wykonywania ograniczonych żądań HTTP do hostów w wewnętrznej sieci serwera Ghost w niektórych konfiguracjach sieciowych. Udany atak nie powodował zwrócenia żadnych danych odpowiedzi. Problem został naprawiony w wersji 6.65.0.

Ghost to system zarządzania treścią oparty na Node.js. Od wersji 6.54.1 do 6.65.0 problem z walidacją umożliwiał nieuwierzytelnionemu użytkownikowi nadużycie niektórych funkcji, takich jak Webmentions, do wykonywania ograniczonych żądań HTTP do hostów w wewnętrznej sieci serwera Ghost. Udany atak nie powodował zwrócenia żadnych danych odpowiedzi. Problem został naprawiony w wersji 6.65.0.