Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Dify to popularna platforma open source wykorzystywana do budowy aplikacji opartych na dużych modelach językowych, workflow AI oraz mechanizmach RAG. Ujawniony zestaw podatności nazwany DifyTap pokazał jednak, że nawet dojrzałe środowiska LLMOps mogą zawierać błędy umożliwiające naruszenie poufności danych, obejście kontroli dostępu i dostęp do wewnętrznych usług.
W praktyce problem dotyczył nie tylko pojedynczej funkcji, ale całego łańcucha słabości obejmującego tracing, obsługę pluginów, podgląd dokumentów i operacje na plikach. To szczególnie istotne w środowiskach multi-tenant, gdzie jeden błąd autoryzacji może otworzyć drogę do danych innych klientów korzystających z tej samej infrastruktury.
W skrócie
- Badacze ujawnili cztery podatności w Dify, w tym dwie o charakterze krytycznym.
- Dwie luki mogły zostać wykorzystane bez uwierzytelnienia.
- Trzy z opisanych błędów miały charakter cross-tenant, czyli umożliwiały dostęp do danych innych klientów.
- Atakujący mogli przechwytywać rozmowy z modelami AI, odczytywać dokumenty oraz wykonywać żądania do wewnętrznych endpointów.
- Producent opublikował poprawki obejmujące kluczowe elementy łańcucha ataku.
Kontekst / historia
Dify zdobyło dużą popularność jako platforma upraszczająca wdrażanie chatbotów, agentów AI i procesów automatyzacji opartych na modelach językowych. Dzięki dostępności zarówno w środowiskach lokalnych, jak i chmurowych, rozwiązanie stało się atrakcyjne dla firm budujących produkcyjne usługi generatywnej sztucznej inteligencji.
W takich wdrożeniach centralne znaczenie ma prawidłowa separacja tenantów. Gdy wiele organizacji współdzieli zaplecze aplikacyjne, każda luka w logice autoryzacji może skutkować wyciekiem danych między klientami. W przypadku DifyTap badacze wskazali właśnie na problemy z egzekwowaniem granic między tenantami oraz z ochroną zasobów przypisanych do konkretnych użytkowników i aplikacji.
Dodatkowym elementem ryzyka okazało się wykorzystanie podatnej wersji biblioteki PDFium do przetwarzania plików PDF. To rozszerzało powierzchnię ataku poza klasyczne błędy logiki biznesowej i pokazywało, że zagrożenie obejmuje również komponenty binarne odpowiedzialne za analizę nieufnych plików.
Analiza techniczna
Najpoważniejsza luka, oznaczona jako CVE-2026-41947, dotyczyła mechanizmu trace’owania. Funkcja tracingu służy do monitorowania działania aplikacji AI, w tym przepływu żądań, odpowiedzi modeli, liczby tokenów i czasu przetwarzania. W tym przypadku endpointy odpowiedzialne za konfigurację śledzenia nie weryfikowały prawidłowo kontekstu tenanta. Oznaczało to, że użytkownik posiadający konto w konsoli mógł utworzyć własny kanał trace dla aplikacji, do której miał dostęp jako zwykły klient, i w ten sposób uzyskać trwały wgląd w komunikację z modelem.
Druga krytyczna podatność, CVE-2026-41948, została znaleziona w komponencie Plugin Daemon, czyli wewnętrznej usłudze obsługującej ekosystem wtyczek. Badacze opisali dwa mechanizmy pozwalające dotrzeć do arbitralnych endpointów tego serwisu. Wariant oparty na metodzie GET wynikał z niewłaściwej sanityzacji parametru nazwy pliku, co otwierało drogę do path traversal. Dodatkowo endpoint pobierania ikon wtyczek nie wymagał logowania, więc atak mógł być wykonany zdalnie. W wariancie POST podobny problem dotyczył endpointu usuwania zadań.
Kolejne dwie luki, CVE-2026-41949 i CVE-2026-41950, dotyczyły kontroli dostępu do plików. Pierwsza umożliwiała użytkownikowi konsoli podgląd dowolnego dokumentu w systemie, ponieważ endpoint weryfikował jedynie typ obiektu, pomijając właściciela i tenant. Druga pozwalała dołączyć identyfikator UUID pliku należącego do innego użytkownika do własnej wiadomości w czacie, a następnie wykorzystać chatbota jako pośrednika do odczytu treści tego pliku.
To ważny przykład nowego wzorca ryzyka w systemach AI. Nawet jeśli aplikacja nie ujawnia zasobu bezpośrednio, model językowy może zostać wykorzystany jako warstwa pośrednia do eksfiltracji danych. W efekcie klasyczne błędy autoryzacji stają się jeszcze bardziej niebezpieczne, ponieważ mogą być łączone z zachowaniem aplikacji opartych na LLM.
Na uwagę zasługuje też kwestia zależności binarnych. Ustalono, że Dify przez długi czas korzystało z wersji PDFium podatnej na CVE-2024-5846, czyli błąd use-after-free. Przy odpowiednio spreparowanym pliku PDF taki komponent mógł potencjalnie stać się punktem wejścia do dalszego ataku na stos przetwarzania dokumentów.
Konsekwencje / ryzyko
Skutki opisanych luk mogą być poważne zarówno dla dostawców usług AI, jak i organizacji korzystających z Dify we własnych środowiskach. Przejęcie historii rozmów z modelami może prowadzić do ujawnienia danych klientów, fragmentów kodu, treści promptów, analiz dokumentów, danych operacyjnych oraz informacji biznesowych.
Szczególnie groźne są podatności cross-tenant, ponieważ uderzają w podstawowy mechanizm bezpieczeństwa usług wielodostępnych. Jeśli jeden klient może uzyskać wgląd w zasoby innego, problem wykracza poza pojedynczy incydent techniczny i staje się zagrożeniem dla zgodności, reputacji i bezpieczeństwa całej platformy.
Dostęp do dokumentów innych użytkowników może oznaczać wyciek umów, danych HR, informacji finansowych, dokumentacji technicznej czy materiałów objętych tajemnicą przedsiębiorstwa. Z kolei możliwość komunikacji z wewnętrznym API Plugin Daemon zwiększa ryzyko dalszej eskalacji, nadużyć w procesach pluginów i eksploracji funkcji normalnie niewidocznych z zewnątrz.
Ryzyko dotyczy zarówno modelu SaaS, jak i wdrożeń lokalnych. W środowiskach chmurowych najgroźniejszy jest wyciek pomiędzy tenantami, natomiast w instalacjach on-premise potencjalny zasięg może być mniejszy, ale przechowywane dane często mają znacznie wyższą wartość dla atakującego.
Rekomendacje
Organizacje korzystające z Dify powinny przede wszystkim sprawdzić, czy używane instancje działają na podatnych wersjach, a następnie niezwłocznie wdrożyć dostępne poprawki. Aktualizacja powinna objąć nie tylko główną aplikację, ale również komponenty towarzyszące i zależności wykorzystywane przy przetwarzaniu plików.
W środowiskach produkcyjnych warto dodatkowo ograniczyć powierzchnię ataku poprzez segmentację sieci, blokowanie nadmiernej ekspozycji usług wewnętrznych oraz monitorowanie ruchu do endpointów pluginów i mechanizmów obsługi plików. Szczególne znaczenie ma też analiza logów pod kątem nietypowych zmian konfiguracji tracingu oraz odczytów dokumentów poza normalnym profilem użycia.
- zweryfikować wersję Dify i wdrożyć wszystkie opublikowane poprawki,
- ograniczyć dostęp sieciowy do usług wewnętrznych, w tym Plugin Daemon,
- wdrożyć ochronę przed path traversal i anomaliami w endpointach plikowych,
- egzekwować ścisłą walidację tenant context w każdym endpointcie,
- sprawdzać uprawnienia właściciela zasobu przy operacjach na dokumentach i plikach,
- objąć parsery plików sandboxingiem i regularnym skanowaniem zależności,
- przeprowadzić przegląd logów i ocenę potencjalnego zakresu wycieku danych.
Podsumowanie
DifyTap pokazuje, że platformy LLMOps stają się pełnoprawnym celem zaawansowanych ataków i muszą być oceniane tak samo rygorystycznie jak inne systemy krytyczne. Połączenie błędów autoryzacji, problemów z izolacją tenantów i ryzyka wynikającego z przetwarzania nieufnych plików tworzy niebezpieczny łańcuch, który może prowadzić do poważnych naruszeń poufności.
Najważniejszy wniosek jest prosty: wdrożenia AI nie mogą funkcjonować poza standardowym programem bezpieczeństwa organizacji. Potrzebują regularnego zarządzania podatnościami, segmentacji, monitoringu, przeglądów uprawnień i twardych kontroli dostępu na każdym poziomie architektury.
Źródła
- DifyTap: Four Bugs Put over 1 million AI Apps at Risk — https://securityaffairs.com/194081/hacking/difytap-four-bugs-put-over-1-million-ai-apps-at-risk.html
- DifyTap: Zafran discovers how attackers can silently wiretap AI data across tenants on a platform powering 1M+ apps — https://www.zafran.io/resources/difytap-zafran-discovers-how-attackers-can-silently-wiretap-ai-data-across-tenants-on-a-platform-powering-1m-apps
- Release v1.14.2 – Security fixes, agent groundwork, workflow reliability, and deployment updates — https://github.com/langgenius/dify/releases/tag/1.14.2