Katalog podatności CVE

W systemie HospitalManagementSystem od onetwothreeneth do wersji 9ef91ed6007314b6473110ed699dff76d158f61d zidentyfikowano podatność w nieznanej funkcji pliku php/controller.php. Manipulacja argumentem transaction_idS prowadzi do wstrzyknięcia SQL. Atak może być wykonany zdalnie. Exploit został ujawniony publicznie i może być użyty. Projekt nie odpowiedział na zgłoszenie.

W systemie onetwothreeneth HospitalManagementSystem wykryto błąd w funkcji update_subaccount w pliku php/controller.php (komponent Account Administration). Manipulacja argumentem user_id prowadzi do nieprawidłowej autoryzacji, a podatność może być wykorzystana zdalnie. Exploit został opublikowany i może być użyty.

W narzędziu Plane (wersje od 0.13 do 1.4.0) endpoint InstanceAdminSignUpEndpoint używa InstanceAdmin.objects.first() do sprawdzenia pierwszego administratora i tworzy konto bez transakcji atomowej, blokady wiersza czy zabezpieczenia unikalności. Dwa równoczesne nieuwierzytelnione żądania z różnymi adresami e-mail mogą oba uznać, że nie istnieje administrator instancji, utworzyć osobne konta i otrzymać sesje z uprawnieniami administratora instancji.

Plane to narzędzie do zarządzania projektami typu open-source. Przed wersją 1.4.0 endpoint cykli przyjmuje UUID problemów w treści żądania bez walidacji, czy należą one do przestrzeni roboczej wywołującego. Uwierzytelniony użytkownik może dodać problemy z dowolnej przestrzeni roboczej do cyklu, który kontroluje. Jeśli problem ofiary jest już przypisany do cyklu, operacja usuwa go z cyklu ofiary, powodując destrukcyjny zapis między dzierżawcami. Problem naprawiono w wersji 1.4.0.

W Plane przed wersją 1.4.0 endpoint GET /api/workspaces/{slug}/entity-search/?query_type=user_mention zwraca nazwy wyświetlane, UUID i adresy URL awatarów członków workspace każdemu uwierzytelnionemu użytkownikowi znającemu slug workspace, nawet jeśli nie jest członkiem. Endpoint ujawnia również wiersze ProjectMember w tej samej sytuacji, ponieważ SearchEndpoint dziedziczy BaseAPIView tylko z permission_classes = [IsAuthenticated] i nie sprawdza członkostwa w workspace.

Plane to narzędzie do zarządzania projektami typu open-source. Przed wersją 1.4.0 endpointy BulkDeleteIssuesEndpoint i SubIssuesEndpoint w apps/api/plane/app/views/issue/ przyjmują identyfikatory problemów z treści żądania lub URL i operują na nich bez sprawdzania, czy należą do przestrzeni roboczej i projektu wywołującego. Dekorator uprawnień na każdym endpointcie sprawdza tylko, czy wywołujący jest członkiem lub administratorem przestrzeni roboczej i projektu wymienionych w URL. BulkDeleteIssuesEndpoint może zniszczyć asocjacje CycleIssue i ModuleIssue należące do obcych problemów. SubIssuesEndpoint może przenieść obce problemy pod wybrany przez atakującego problem i zwrócić metadane obcych problemów. Problem naprawiono w wersji 1.4.0.

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.

Plane to narzędzie do zarządzania projektami typu open-source. Przed wersją 1.4.0 endpoint relacji problemów przyjmuje UUID problemów w treści żądania bez walidacji, czy należą one do przestrzeni roboczej wywołującego. Uwierzytelniony użytkownik może tworzyć relacje łączące jego własne problemy z problemami w dowolnej innej przestrzeni roboczej, co prowadzi do wycieku metadanych problemów przez zdarzenia aktywności. Problem naprawiono w wersji 1.4.0.

Plane to narzędzie do zarządzania projektami typu open-source. Przed wersją 1.4.0 endpoint aktualizacji projektu autoryzuje wywołującego na podstawie sluga przestrzeni roboczej w URL, ale ładuje docelowy projekt globalnie po UUID bez powiązania z tą przestrzenią roboczą. Administrator jednej przestrzeni roboczej może modyfikować projekt w innej przestrzeni roboczej, jeśli zna UUID projektu ofiary. Narusza to izolację dzierżawców i pozwala na nieautoryzowane zmiany metadanych i konfiguracji projektu między przestrzeniami roboczymi. Problem naprawiono w wersji 1.4.0.

Plane to narzędzie do zarządzania projektami typu open-source. Przed wersją 1.4.0 endpointy GET /api/workspaces/{slug}/cycles/ (WorkspaceCyclesEndpoint) i GET /api/workspaces/{slug}/modules/ (WorkspaceModulesEndpoint) zwracają rekordy ze wszystkich projektów w przestrzeni roboczej bez sprawdzania, czy wywołujący należy do każdego projektu. Każdy uwierzytelniony członek przestrzeni roboczej, w tym Gość z dostępem tylko do jednego projektu, może wyliczyć nazwy, opisy, daty sprintów, liczby problemów, migawki postępu, zewnętrzne identyfikatory integracji, powiązane URL-e i listy członków dla cykli i modułów w prywatnych projektach. Sąsiednie endpointy WorkspaceLabelsEndpoint i WorkspaceStatesEndpoint stosują odpowiedni filtr, co czyni endpointy cykli i modułów niespójnymi. Problem naprawiono w wersji 1.4.0.

Przed wersją 1.4.0 narzędzia Plane, endpoint GET /api/v1/workspaces/{slug}/projects/{project_id}/members/ ujawnia pełną listę członków projektu, w tym adresy e-mail, imiona i nazwiska, awatary i role. Kontrola dostępu ProjectMemberPermission sprawdza tylko, czy użytkownik jest aktywnym członkiem dowolnego projektu w workspace, ale nie wiąże tego z konkretnym project_id. W rezultacie każdy uwierzytelniony użytkownik należący do jednego projektu, w tym Gość, może odczytać listę członków innego prywatnego projektu w tym samym workspace.

Przed wersją 1.4.0 narzędzia Plane, uprawnienie WorkspaceOwnerPermission nie wymaga, aby użytkownik miał ustawione is_active=True podczas sprawdzania, czy jest właścicielem workspace. Dezaktywowany użytkownik może pozostać autoryzowany jako właściciel workspace i zachować dostęp na poziomie właściciela.

Przed wersją 1.4.0 narzędzia Plane, endpoint GET /api/assets/v2/workspaces/{workspace_slug}/download/{asset_id}/ umożliwia pobieranie plików przypisanych do projektów bez sprawdzania dostępu do projektu, do którego należą. Uwierzytelniony użytkownik z tego samego workspace, niebędący członkiem tajnego projektu, znając UUID zasobu, może otrzymać przekierowanie 302 do podpisanego URL-a pobierania. Dotyczy to typów ISSUE_ATTACHMENT, COMMENT_DESCRIPTION, PAGE_DESCRIPTION i PROJECT_COVER.

Przed wersją 1.4.0 narzędzia Plane, nieuwierzytelniony endpoint publicznych zgłoszeń przyjmuje parametry group_by i sub_group_by bez listy dozwolonych wartości i przekazuje je do paginatorów, gdzie są używane jako nazwy pól ORM. Atakujący może podać dowolne ścieżki pól, co powoduje nieobsłużone błędy FieldError lub KeyError i odpowiedź HTTP 500, lub może wykorzystać to jako wyrocznię do ślepej eksploracji relacyjnych ścieżek. Poprawka z wcześniejszej wersji nie objęła tych parametrów.

Przed wersją 1.4.0 narzędzia Plane, członek projektu z rolą 15 może wysłać żądanie PATCH do endpointu aktualizacji członków projektu i zmienić rolę innego użytkownika. Logika aktualizacji roli blokuje tylko nową rolę wyższą niż rola żądającego, więc przypisanie równej roli Member omija walidację i awansuje Gościa projektu z rolą 5 do roli Member bez zgody administratora projektu.

Przed wersją 1.4.0 narzędzia Plane, endpoint modułów przyjmuje identyfikatory UUID zgłoszeń w ścieżce URL bez walidacji, czy należą one do workspace wywołującego. Uwierzytelniony użytkownik może linkować zgłoszenia z dowolnego workspace do modułów w swoim własnym workspace.

Przed wersją 1.4.0 narzędzia Plane, endpoint GET /api/users/api-tokens/ pozwala uwierzytelnionemu użytkownikowi pobierać rekordy tokenów API, a PATCH /api/users/api-tokens/{token_id}/ pozwala modyfikować pole allowed_rate_limit bez walidacji po stronie serwera. Użytkownik może dowolnie podnieść limit i ominąć limity API, co umożliwia wysoką liczbę automatycznych żądań i potencjalne wyczerpanie zasobów.

Rozszerzenie Joomla TF Content w wersjach 2.9.0 - 2.9.4 udostępnia zadanie `records.custom_action` bez uwierzytelnienia, kontroli ACL, CSRF, wyzwalacza zadań, powiązania z treścią lub tokena cron. Gość może podać numeryczny ID dowolnego opublikowanego zadania TF Content i wymusić natychmiastowe wykonanie skonfigurowanego executora.

Rozszerzenie Joomla Event Gallery w wersji < 6.6.0 zawiera podatność na SSRF w selektorze Google Photos na stronie przesyłania plików. Selektor pobiera miniatury wybranych obrazów przez serwer, używając tokena OAuth konta Google Photos. Zadanie pobiera adres z żądania bez sprawdzenia i nie wymaga tokena formularza. Przygotowana strona na innym serwisie może sprawić, że serwer wyśle token dostępu konta na dowolny adres lub pobierze adresy wewnątrz sieci serwera w imieniu zalogowanego administratora.

Biblioteka adm-zip przed wersją 0.6.1 stosuje uniksowe bity uprawnień z wpisu ZIP bezpośrednio do rozpakowanego pliku przez fs.chmodSync(), gdy keepOriginalPermission=true jest przekazane do extractAllTo()/extractEntryTo() — i nigdy nie filtruje bitów setuid/setgid/sticky. Złośliwy ZIP może utworzyć plik wykonywalny z mode 04755, co przy rozpakowywaniu jako root prowadzi do wykonania kodu atakującego z uprawnieniami roota.