Co znajdziesz w tym artykule?
Wprowadzenie do problemu
Dify to otwartoźródłowa platforma do budowy aplikacji oraz workflow opartych na sztucznej inteligencji, często wykorzystywana w środowiskach wielodzierżawnych. W takim modelu kluczowe znaczenie ma ścisła separacja tenantów, czyli pełne odizolowanie danych, konfiguracji i zasobów poszczególnych klientów. Ujawnione podatności pokazują jednak, że błędy w autoryzacji i walidacji ścieżek mogły naruszać tę granicę.
Zestaw luk nazwany DifyTap dotyczył mechanizmów odpowiedzialnych za śledzenie działania aplikacji, obsługę plików oraz komunikację z komponentem Plugin Daemon. W praktyce błędy te mogły prowadzić do odczytu prywatnych konwersacji AI, podglądu dokumentów oraz nieautoryzowanego dostępu do zasobów należących do innych tenantów.
W skrócie
Badacze opisali cztery podatności wpływające na bezpieczeństwo platformy Dify. Dwie z nich miały charakter krytyczny i umożliwiały obejście mechanizmów izolacji tenantów, co w środowiskach współdzielonych stanowi szczególnie poważne zagrożenie.
- CVE-2026-41947 dotyczyła obejścia autoryzacji w konfiguracji trace.
- CVE-2026-41948 była podatnością path traversal w interfejsie Plugin Daemon.
- CVE-2026-41949 umożliwiała podgląd fragmentów plików innych klientów.
- CVE-2026-41950 pozwalała na odczyt plików innych użytkowników w obrębie tego samego tenanta.
- Dodatkowo zwrócono uwagę na obecność komponentu PDFium podatnego na CVE-2024-5846.
Kontekst i historia
Rosnąca popularność platform AI sprawia, że coraz większe znaczenie mają nie tylko same modele, ale również warstwa orkiestracji, pluginów, przechowywania plików i mechanizmów obserwowalności. To właśnie w tych obszarach często ujawniają się błędy logiczne, które nie wymagają zaawansowanego exploitu, lecz wykorzystują brak właściwej kontroli właściciela zasobu.
W przypadku DifyTap wspólnym mianownikiem wszystkich problemów był niedostatecznie wymuszany model tenant-aware access control. Oznacza to, że system nie zawsze sprawdzał, czy użytkownik wykonujący operację rzeczywiście należy do tego samego workspace’u lub tenanta co aplikacja, plik czy konfiguracja, do której próbował uzyskać dostęp.
Analiza techniczna
Najpoważniejszy scenariusz dotyczył mechanizmu trace. Luka CVE-2026-41947 pozwalała uwierzytelnionemu użytkownikowi z odpowiednimi uprawnieniami ustawić konfigurację śledzenia dla aplikacji, która nie należała do jego tenanta. W konsekwencji atakujący mógł przekierować dane telemetryczne, w tym treści zapytań i odpowiedzi modelu, do kontrolowanego przez siebie dostawcy trace. Taki wektor tworzył kanał eksfiltracji trudny do wykrycia, ponieważ działał na poziomie obserwowalności, a nie samej logiki czatu.
Druga krytyczna luka, CVE-2026-41948, była związana z błędną normalizacją ścieżek w żądaniach kierowanych do wewnętrznego API Plugin Daemon. Manipulacja ścieżką lub parametrami mogła umożliwić wyjście poza dozwolony kontekst i uzyskanie dostępu do prywatnych endpointów. Tego typu błąd jest szczególnie niebezpieczny w komponentach pośredniczących, ponieważ może otwierać drogę do dalszej eskalacji lub dostępu do wrażliwych operacji wykonywanych przez rozszerzenia.
CVE-2026-41949 dotyczyła endpointu podglądu plików. Przy znajomości identyfikatora UUID pliku uwierzytelniony użytkownik mógł odczytać fragment dokumentu należącego do innego klienta. Choć zakres danych był ograniczony, nawet częściowy podgląd treści może ujawnić informacje wystarczające do dalszego rozpoznania środowiska, identyfikacji sekretów lub potwierdzenia wartości przechowywanych danych.
CVE-2026-41950 rozszerzała ryzyko na poziomie tego samego tenanta. Błąd przypominał klasyczny IDOR i wynikał z braku odpowiedniego sprawdzenia relacji pomiędzy użytkownikiem, plikiem oraz kontekstem rozmowy. Dzięki temu możliwy był odczyt pełnej zawartości plików przesłanych przez innych użytkowników poprzez odpowiednio przygotowane żądanie.
Osobnym problemem była obecność podatnej wersji PDFium związanej z CVE-2024-5846. Choć nie stanowiło to bezpośredniego elementu pakietu DifyTap, zwiększało powierzchnię ataku w obszarze przetwarzania dokumentów, zwłaszcza jeśli platforma akceptowała pliki PDF od użytkowników lub integrowała je z procesami AI.
Konsekwencje i ryzyko
Dla organizacji korzystających z Dify najpoważniejsze ryzyko dotyczy naruszenia poufności. W środowiskach, w których do modeli AI trafiają dokumenty biznesowe, kod źródłowy, dane klientów, informacje handlowe lub treści objęte tajemnicą przedsiębiorstwa, możliwość podglądu czatów i załączników przez nieuprawniony podmiot może prowadzić do poważnych skutków operacyjnych i regulacyjnych.
Scenariusz cross-tenant jest szczególnie groźny, ponieważ podważa podstawowe założenie bezpieczeństwa usług wielodzierżawnych. Jeżeli jedna organizacja może uzyskać wgląd w dane drugiej wskutek błędu aplikacyjnego, problem wykracza poza lokalny incydent i staje się zagrożeniem systemowym dla całej platformy.
Nie bez znaczenia pozostaje także ryzyko trudnej detekcji. Wariant wykorzystujący konfigurację trace może działać dyskretnie i przez dłuższy czas pozostać niezauważony, zwłaszcza jeśli monitoring nie obejmuje zmian w warstwie obserwowalności lub nie koreluje ich z właścicielem aplikacji i tenantem.
Rekomendacje
Administratorzy powinni w pierwszej kolejności zweryfikować używaną wersję Dify oraz wdrożyć dostępne poprawki bezpieczeństwa. Równie ważne jest sprawdzenie, czy po aktualizacji wykonano wszystkie wymagane migracje i czy lokalne modyfikacje konfiguracji nie osłabiły kontroli dostępu.
- Zweryfikować wersję platformy i przeprowadzić aktualizację co najmniej do wydania usuwającego opisane luki.
- Przejrzeć konfigurację trace i ograniczyć możliwość jej modyfikacji wyłącznie do zaufanych administratorów.
- Monitorować operacje na endpointach preview, chat-messages i zasobach plikowych pod kątem nietypowych UUID.
- Audytować ruch do Plugin Daemon i wykrywać anomalie wskazujące na próby path traversal.
- Przeanalizować logi pod kątem nieautoryzowanych zmian konfiguracji oraz dostępu do dokumentów.
- Zaktualizować biblioteki odpowiedzialne za przetwarzanie plików, w tym komponenty PDF.
- Rozważyć segmentację usług AI, magazynu plików i warstwy pluginów w celu ograniczenia skutków ewentualnej kompromitacji.
Z perspektywy architektonicznej warto również przeprowadzić przegląd wszystkich operacji wykonywanych na aplikacjach, plikach, workflow i sesjach. Każda z nich powinna jawnie weryfikować właściciela zasobu oraz przynależność tenantową, a nie opierać się jedynie na fakcie uwierzytelnienia użytkownika.
Podsumowanie
DifyTap to przykład tego, jak krytyczne ryzyko w platformach AI może wynikać nie z samych modeli, lecz z błędów w orkiestracji, autoryzacji, obsłudze plików i komponentach pośrednich. Połączenie luk typu authorization bypass, path traversal oraz IDOR stworzyło warunki do odczytu konwersacji AI i dokumentów pomiędzy tenantami.
Dla zespołów bezpieczeństwa to ważny sygnał ostrzegawczy: ocena ryzyka wdrożeń AI musi obejmować cały ekosystem aplikacyjny, a nie wyłącznie warstwę modelową. Organizacje korzystające z Dify powinny potraktować aktualizacje, audyt izolacji tenantów i kontrolę komponentów plikowych jako działania priorytetowe.
Źródła
- The Hacker News — https://thehackernews.com/2026/06/researchers-detail-difytap-flaws-in.html
- NVD — CVE-2026-41948 — https://nvd.nist.gov/vuln/detail/CVE-2026-41948
- GitHub Releases — langgenius/dify v1.14.2 — https://github.com/langgenius/dify/releases
- NVD — CVE-2024-5846 — https://nvd.nist.gov/vuln/detail/CVE-2024-5846
- GitHub Repository — langgenius/dify — https://github.com/langgenius/dify