CVE-2026-48737

W pyLoad przed wersją 0.5.0b3.dev101 funkcja Api.check_apikey buforuje udaną walidację w self._apikey_cache wyłącznie na podstawie kontrolowanego przez atakującego key_id. Po zapełnieniu cache przez prawidłowy klucz sfałszowany klucz API o tym samym key_id trafia na ścieżkę cache-hit bez porównania apikey[-43:] z zapisanym hashem przez hmac.compare_digest. Ponieważ identyfikatory kluczy to małe kolejne liczby całkowite, nieuwierzytelniony zdalny atakujący może wyliczyć aktywny identyfikator i przejąć uprawnienia właściciela klucza w ciągu 300 sekund życia cache.

W menedżerze pobierania pyLoad w wersjach przed 0.5.0b3.dev102 uwierzytelniony użytkownik niebędący administratorem, posiadający uprawnienie SETTINGS, może skonfigurować WindowsPhoneNotify poprzez /json/save_config, ustawiając pushurl, pushid i enabled. Następnie WindowsPhoneNotify.send używa http.client.HTTPConnection bez walidacji celu pyLoad, co pozwala na ślepe wysłanie żądania POST z serwera pyLoad do wewnętrznego hosta, portu i ścieżki wybranych przez atakującego.

W pyLoad przed wersją 0.5.0b3.dev102 zmiana uprawnień lub hasła użytkownika przez administratora przez /api/set_user_permission lub /api/change_password nie unieważnia istniejących sesji Flask. Funkcje Api.set_user_permission i Api.change_password aktualizują bazę danych, ale autoryzacja sesji nadal korzysta z ról i uprawnień skopiowanych przy logowaniu przez set_session w webui/app/helpers.py. Użytkownik może więc zachować odebrane uprawnienia lub dalej używać sesji założonej starym hasłem przez skonfigurowany czas życia sesji.

W pyLoad przed wersją 0.5.0b3.dev100 występuje podatność, która pozwala użytkownikowi z uprawnieniami Perms.MODIFY na określenie dowolnych katalogów jako lokalizacji pobierania pakietu poprzez funkcję API set_package_data(). Brak sanitizacji w kluczu '_folder' umożliwia to działanie.

W pyLoad przed wersją 0.5.0b3.dev100 metoda API set_config_value() nieprawidłowo zarządzała opcjami bezpieczeństwa, co pozwalało uwierzytelnionym użytkownikom z uprawnieniami do ustawień na włączenie proxy i skierowanie ruchu przez kontrolowany przez nich host.

W pyLoad funkcja UnTar._safe_extractall waliduje ścieżki elementów archiwum i cele linków, ale nie wywołuje TarInfo.isdev, aby odrzucić specjalne typy elementów tar przed wywołaniem tarfile.extractall. W Pythonie 3.9–3.13 tarfile domyślnie używa filtra fully_trusted, więc użytkownik z uprawnieniami ADD i STATUS może spowodować rozpakowanie archiwum zawierającego urządzenia znakowe, blokowe lub FIFO. Gdy pyLoad działa z uprawnieniami systemowymi (np. oficjalny Docker jako root), może to ujawnić surowe urządzenia i naruszyć bezpieczeństwo hosta.

pyLoad w wersji 0.5.0b3.dev96 i wcześniejszych zawiera podatność SSRF. Poprawka dla CVE-2026-33992 dodała walidację IP, ale pycurl automatycznie podąża za przekierowaniami HTTP, a cele przekierowań nie są sprawdzane. Uwierzytelniony użytkownik z uprawnieniami ADD może ominąć filtr SSRF, używając URL przekierowującego do wewnętrznego adresu.

Podatność w pyLoad, menedżerze pobierania, gdzie trasa `/web/<path:filename>` renderuje szablony Jinja2 bez wymaganego uwierzytelnienia. Dodatkowo literówka w obsłudze wyjątków powoduje wyciek wewnętrznych nazw zmiennych Jinja2 w odpowiedziach HTTP 500.

Podatność w pyLoad, menedżerze pobierania, gdzie funkcja API `rpc` odczytuje całą zawartość przesłanego pliku do pamięci bez limitu rozmiaru, co może doprowadzić do wyczerpania pamięci serwera i zakończenia procesu.

W pyLoad przed wersją 0.5.0b3.dev101 klasa EventManager w src/pyload/core/managers/event_manager.py dodaje obiekt Client do listy klientów dla każdego unikalnego UUID przesłanego do uwierzytelnionego endpointu API getEvents, ale get_events nie wywołuje dostępnej metody clean usuwającej nieaktywnych klientów. Uwierzytelniony użytkownik może wielokrotnie przesyłać unikalne wartości UUID, powodując nieograniczony wzrost liczby obiektów klientów i pamięci procesu.