CVE-2026-119329

Immich, rozwiązanie do zarządzania zdjęciami i filmami, ma podatność na refleksyjny atak XSS na stronie /auth/login. Atakujący może przejąć konto uwierzytelnionego użytkownika za pomocą jednego kliknięcia w link.

W Immich w wersjach przed 3.2.0 API tworzenia linków współdzielonych przyjmowało albumId i assetIds jako niezależne pola w server/src/services/shared-link.service.ts, ale autoryzowało tylko zasób wybrany przez żądany typ linku. Uwierzytelniony atakujący, który znał UUID zasobu należącego do ofiary, mógł wybrać SharedLinkType.Album dla własnego albumu, podając ten UUID w assetIds; SharedLinkService.create() zapisywał niezweryfikowane powiązanie w shared_link_asset i udostępniał zasób ofiary przez nowe anonimowe poświadczenie linku współdzielonego.

W Immich przed wersją 3.3.0 nieuwierzytelniony punkt końcowy /predict usługi uczenia maszynowego przyjmował obiekt opcji bez ograniczania parametrów wrażliwych na bezpieczeństwo. Atakujący z dostępem sieciowym mógł ustawić cache_dir na dowolną zapisywalną ścieżkę, powodując zapis pobieranych modeli oraz rekurencyjne usunięcie wybranego katalogu przez shutil.rmtree().

Immich do wersji 3.3.1 zawiera podatność na brak autoryzacji w strumieniu synchronizacji partnerów, która pozwala uwierzytelnionym partnerom odczytywać metadane zasobów w zablokowanych folderach, ponieważ zapytania synchronizacji nie wykluczają widoczności Locked. Atakujący z aktywną relacją partnerską mogą wywołać POST /api/sync/stream z typami PartnerAssetsV2 i PartnerAssetExifsV1, aby uzyskać współrzędne GPS, czasy przechwycenia, opisy i szczegóły aparatu.

Immich to wysokowydajne samodzielnie hostowane rozwiązanie do zarządzania zdjęciami i filmami. Przed wersją 3.2.4 uwierzytelniony użytkownik niebędący administratorem mógł przesyłać pliki SVG, które kod generowania miniatur w server/src/repositories/media.repository.ts przekazywał do libvips. Pliki, które ominęły natywny loader SVG libvips, trafiały do ImageMagick, gdzie wartości <image href> kontrolowane przez atakującego docierały do nieograniczonych operacji MSL i VIDEO coder. Przechowując jeden spreparowany zasób i odwołując się do jego ścieżki z drugiego SVG z opóźnionym znacznikiem, atakujący mógł wykonać kod w kontenerze immich-server podczas przetwarzania miniatur. Problem naprawiono w wersji 3.2.4.

W immich-app Immich do wersji 2.7.5 wykryto podatność w funkcji checkSharedLinkAccess w pliku server/src/utils/access.ts, dotyczącą obsługi podglądu udostępnionych linków. Manipulacja argumentem Password prowadzi do nieprawidłowej autoryzacji. Zgłoszenie na GitHubie zostało zamknięte jako duplikat.

Immich do wersji 3.1.0 nie egzekwuje prawidłowo widoczności zablokowanych zasobów, gdy zasoby są blokowane przez punkt końcowy pojedynczego zasobu, co pozwala im pozostać dostępnymi przez udostępnione albumy i linki. Atakujący mogą odczytać zablokowane zasoby i ich metadane, uzyskując dostęp do istniejących udostępnionych albumów lub linków, omijając ochronę widoczności zablokowanych zasobów.

Podatność w systemie Immich przed wersją 3.0.3 w punkcie końcowym PUT /albums/:id/user/:userId pozwala edytorom współdzielonych albumów na zmianę ról członków bez wymaganych uprawnień właściciela. Atakujący z dostępem edytora może w sekwencyjnych żądaniach zdegradować właściciela albumu do roli edytora i awansować siebie na właściciela, uzyskując pełną kontrolę nad albumem.

Immich przed wersją 2.7.0 zawiera podatność Stored XSS w przeglądarce panoram 360°. Uwierzytelniony użytkownik może przesłać złośliwy obraz, którego tekst po OCR jest renderowany bez sanityzacji, co pozwala na wykonanie dowolnego JavaScriptu w przeglądarce innych użytkowników.

Immich przed wersją 2.6.0 ma podatność na ujawnienie poświadczeń podczas uwierzytelniania do udostępnionego albumu. Hasło albumu jest przesyłane w parametrach zapytania URL w żądaniu GET do /api/shared-links/me, co naraża je na zapis w historii przeglądarki, logach proxy i serwera oraz nagłówkach referrer.