CVE-2026-61461

Wersja 1.14.1 i wcześniejsze Dify zawierają podatność na przejście ścieżki, która pozwala uwierzytelnionym użytkownikom manipulować żądaniami kierowanymi do wewnętrznego API REST Plugin Daemon. Atakujący mogą wykorzystać niewystarczające oczyszczanie ścieżek URL, aby uzyskać dostęp do wewnętrznych punktów końcowych.

Dify przed wersją 1.14.2 zawiera lukę w autoryzacji, która pozwala uwierzytelnionym użytkownikom edytorów na ustawianie i włączanie konfiguracji śledzenia dla dowolnej aplikacji, niezależnie od własności najemcy. Luka ta umożliwia atakującym przekierowanie wszystkich wiadomości i odpowiedzi z aplikacji ofiary do kontrolowanych przez nich dostawców śledzenia LLM.

Dify v1.9.1 ma podatność na nieprawidłowe uprawnienia. Nieuwierzytelniony atakujący może wysyłać żądania HTTP GET do endpointu /console/api/system-features bez żadnych poświadczeń. Endpoint nie przeprowadza odpowiednich kontroli autoryzacji, umożliwiając anonimowy dostęp do danych konfiguracyjnych systemu. Producent twierdzi, że endpoint jest celowo nieuwierzytelniony i nie udostępnia wrażliwych danych.

W Dify do wersji 1.5.1 w pliku docker-compose.yaml znajdują się domyślne dane uwierzytelniające do bazy PostgreSQL (nazwa użytkownika i hasło). Producent informuje, że od wersji 1.0.1 PostgreSQL nie jest domyślnie wystawiony na TCP porcie 5432.

Podatność polegająca na błędnej konfiguracji CORS w Dify v1.9.1 w endpointcie /console/api/system-features. Endpoint odzwierciedla dowolne nagłówki Origin i ustawia Access-Control-Allow-Credentials: true, co pozwala zewnętrznym domenom na uwierzytelnione żądania międzyorigin. Uwaga: dostawca kwestionuje tę podatność, argumentując, że żądania z poświadczeniami nie dają dodatkowego dostępu w porównaniu z żądaniami nieuwierzytelnionymi.

Dify to platforma do tworzenia aplikacji LLM o otwartym kodzie źródłowym. Przed wersją 1.13.0 punkt końcowy /console/api/remote-files/upload w api/controllers/web/remote_files.py akceptował adres URL kontrolowany przez atakującego bez uwierzytelnienia i powodował, że serwer Dify go pobierał. Zdalny atakujący mógł użyć tego punktu końcowego do wysyłania żądań do wewnętrznych usług lub punktów końcowych metadanych chmury, potencjalnie ujawniając wrażliwe dane i używając serwera jako punktu przesiadkowego w sieci. Problem naprawiono w wersji 1.13.0.

Dify, platforma do tworzenia aplikacji LLM, przed wersją 1.16.0, w punkcie końcowym PUT /console/api/apps/<app_id>/server, nie weryfikowała, czy serwer MCP należy do żądanej aplikacji i dzierżawcy. Uwierzytelniony członek przestrzeni roboczej mógł zmienić status i parametry serwera MCP innej aplikacji, potencjalnie przekierowując dane lub wyłączając usługę.

Luka bezpieczeństwa w langgenius dify do wersji 1.14.2 włącznie, dotycząca funkcji jinja2.Template w pliku api/core/helper/code_executor/jinja2/jinja2_transformer.py w komponencie Jinja2 Handler, prowadzi do nieprawidłowej neutralizacji specjalnych elementów używanych w silniku szablonów. Atak może być przeprowadzony zdalnie, a exploit jest publicznie dostępny.

Podatność Open Redirect w Dify AI Workflow w komponencie AppInitializer. Atakujący może przekierować użytkownika na złośliwą stronę podczas przepływu OAuth, co wymaga interakcji ofiary (odwiedzenia złośliwej strony lub pliku).

Dify przed wersją 1.14.2 zawiera lukę w autoryzacji w punkcie końcowym podglądu plików, która pozwala każdemu uwierzytelnionemu użytkownikowi na odczytanie do 3,000 znaków z dowolnego przesłanego dokumentu, używając jedynie UUID pliku. Atakujący mogą uzyskać dostęp do końcowego punktu /console/api/files/{file_id}/preview, aby wydobyć wrażliwe treści z dokumentów bez weryfikacji własności lub uprawnień do przestrzeni roboczej.