Четыре уязвимости в платформе Dify, объединённые общим кодовым именем DifyTap, позволяли одному клиенту читать переписки другого, подменять маршруты трассировки и получать доступ к внутренним API. Проект набрал более 146 000 звёзд на GitHub, и именно эта популярность делает находки исследователей из Zafran Security такими неприятными. Авторы отчёта — Идо Шани и Галь Забан.
Что именно сломано
Центральная идея Dify — low-code среда, где можно собирать ИИ-агентов из готовых блоков. Регистрация бесплатна для всех, поэтому даже для атак, требующих авторизации, порог входа минимален: достаточно одного аккаунта. Самая опасная из четырёх брешей — CVE-2026-41947 с оценкой CVSS 9.1. Авторизованный пользователь с правами «редактор» мог подключить свой собственный LLM-провайдер трассировки к любому чужому приложению, в том числе к публично доступному. После этого все запросы и ответы жертвы начинали уходить на подконтрольный исследователю эндпоинт — фактически это готовый канал для тихого слива данных на каждый диалог. Как объясняют исследователи: «Это позволяет атакующему создать постоянный канал эксфильтрации для всех сообщений и ответов в приложении».
Вторая критическая проблема — CVE-2026-41948 с CVSS 9.4. Проверка путей в URL при проксировании запросов к внутреннему Plugin Daemon была недостаточной, и через простые манипуляции с путём атакующий получал доступ к приватным эндпоинтам, которые вообще не должны быть видны снаружи. Это уже не утечка данных, а ход в инфраструктуру: межтенантные вызовы к внутреннему API открывают дорогу к боковому перемещению.
CVE-2026-41949 закрывает чуть меньший, но всё равно неприятный люк: эндпоинт
Зависимость, которая добавила RCE
Параллельно исследователи наткнулись на CVE-2024-5846 — двухлетнюю уязвимость в открытой C++-библиотеке PDFium для рендеринга PDF. Там классический use-after-free с CVSS 8.8, способный привести к повреждению кучи и удалённому выполнению кода через специально сформированный PDF. Dify парсил документы этой библиотекой, и уязвимая версия кочевала из сборки в сборку. Уже знакомая история: сторонние зависимости в LLM-платформах часто живут дольше, чем нужно, и превращаются в неприятный подарок.
Как собирается полная цепочка
На практике эксплуатация выглядит линейно. Регистрация бесплатная → настройка своей конфигурации трассировки для чужого (часто публичного) приложения → перехват всех сообщений и ответов модели в этом приложении. Параллельно через path-traversal можно дотянуться до приватных методов Plugin Daemon, а через UUID файла — прочитать сначала превью чужих документов (3 000 символов), а если повезёт оказаться в одном тенанте с жертвой, то и их полное содержимое. RCE через PDF остаётся «бонусной» веткой для атакующих, которые умеют работать с памятью. В Zafran прямо отмечают: «DifyTap показывает, в чём именно состоит сложность видимости уязвимостей, особенно в образах контейнеров: различия между развёрнутыми инсталляциями создают слепые зоны, которые обычные сканеры не видят».
Почему это важно не только для пользователей Dify
Платформа — типичный представитель нового класса SaaS, где LLM, агенты и пользовательские данные живут в одном облаке и одном тенантном пространстве. Когда проектирование «свернуто в open-source» и разнесено по микросервисам (приложения, плагины, трассировка), ошибки авторизации начинают множиться: где-то забыли проверить владельца трейс-конфигурации, где-то доверились UUID вместо полноценной ACL-проверки, где-то не отфильтровали путь перед проксированием. Подобный паттерн — общий, а не только дифайский. Платформа с 146 000 звёзд GitHub — это просто очень удобный пример, до которого удобно дотянуться.
Что делать
Все четыре «дифайных» CVE закрыты в версии v1.4.2 — она вышла незадолго до публикации отчёта. Обновляться стоит немедленно, особенно тем, кто держит собственные инсталляции для корпоративных клиентов. Правка для PDFium ожидается в следующем релизе — за ним тоже нужно следить. Для тех, кто управляет несколькими развёртываниями Dify в контейнерах, исследователи отдельно подчёркивают: обычные сканеры уязвимостей не всегда понимают, что внутри образа лежит старый PDFium — эффект «дыр между сборками». Здесь пригодятся инструменты, которые смотрят именно в бинарный состав контейнеров, а не только в манифесты и SBOM на бумаге.
Организациям, использующим Dify в продакшене, имеет смысл отдельно проверить, не остались ли следы чужих LLM-провайдеров трассировки в конфигурациях приложений и не было ли подозрительных превью-обращений к чужим UUID в логах — теоретически эти следы могли оставить недобросовестные клиенты ещё до патча.
Инцидент наглядно показывает, к чему приводит комбинация открытой регистрации, многотенантной архитектуры и ИИ-нагрузки: одна забытая авторизационная проверка превращается в канал для перехвата чатов у соседа по облаку.
Что именно сломано
Центральная идея Dify — low-code среда, где можно собирать ИИ-агентов из готовых блоков. Регистрация бесплатна для всех, поэтому даже для атак, требующих авторизации, порог входа минимален: достаточно одного аккаунта. Самая опасная из четырёх брешей — CVE-2026-41947 с оценкой CVSS 9.1. Авторизованный пользователь с правами «редактор» мог подключить свой собственный LLM-провайдер трассировки к любому чужому приложению, в том числе к публично доступному. После этого все запросы и ответы жертвы начинали уходить на подконтрольный исследователю эндпоинт — фактически это готовый канал для тихого слива данных на каждый диалог. Как объясняют исследователи: «Это позволяет атакующему создать постоянный канал эксфильтрации для всех сообщений и ответов в приложении».
Вторая критическая проблема — CVE-2026-41948 с CVSS 9.4. Проверка путей в URL при проксировании запросов к внутреннему Plugin Daemon была недостаточной, и через простые манипуляции с путём атакующий получал доступ к приватным эндпоинтам, которые вообще не должны быть видны снаружи. Это уже не утечка данных, а ход в инфраструктуру: межтенантные вызовы к внутреннему API открывают дорогу к боковому перемещению.
CVE-2026-41949 закрывает чуть меньший, но всё равно неприятный люк: эндпоинт
/console/api/files/{file_id}/preview можно было вызвать с любым UUID, и за авторизацией проверка принадлежности файла не проверялась. В ответ возвращалось до 3 000 символов превью — этого хватает, чтобы вытащить фрагменты документов, загруженных другими клиентами и в других рабочих пространствах. Внутри одного тенанта работала CVE-2026-41950 (CVSS 6.5): достаточно подставить чужой UUID файла в массив files запроса chat-messages, чтобы получить полное содержимое чужого документа. В Zafran суммируют: «Два бага имели критическую степень опасности, два вообще не требовали аутентификации, три были кросс-тенантными и позволяли видеть данные одного клиента другому». Зависимость, которая добавила RCE
Параллельно исследователи наткнулись на CVE-2024-5846 — двухлетнюю уязвимость в открытой C++-библиотеке PDFium для рендеринга PDF. Там классический use-after-free с CVSS 8.8, способный привести к повреждению кучи и удалённому выполнению кода через специально сформированный PDF. Dify парсил документы этой библиотекой, и уязвимая версия кочевала из сборки в сборку. Уже знакомая история: сторонние зависимости в LLM-платформах часто живут дольше, чем нужно, и превращаются в неприятный подарок.
Как собирается полная цепочка
На практике эксплуатация выглядит линейно. Регистрация бесплатная → настройка своей конфигурации трассировки для чужого (часто публичного) приложения → перехват всех сообщений и ответов модели в этом приложении. Параллельно через path-traversal можно дотянуться до приватных методов Plugin Daemon, а через UUID файла — прочитать сначала превью чужих документов (3 000 символов), а если повезёт оказаться в одном тенанте с жертвой, то и их полное содержимое. RCE через PDF остаётся «бонусной» веткой для атакующих, которые умеют работать с памятью. В Zafran прямо отмечают: «DifyTap показывает, в чём именно состоит сложность видимости уязвимостей, особенно в образах контейнеров: различия между развёрнутыми инсталляциями создают слепые зоны, которые обычные сканеры не видят».
Почему это важно не только для пользователей Dify
Платформа — типичный представитель нового класса SaaS, где LLM, агенты и пользовательские данные живут в одном облаке и одном тенантном пространстве. Когда проектирование «свернуто в open-source» и разнесено по микросервисам (приложения, плагины, трассировка), ошибки авторизации начинают множиться: где-то забыли проверить владельца трейс-конфигурации, где-то доверились UUID вместо полноценной ACL-проверки, где-то не отфильтровали путь перед проксированием. Подобный паттерн — общий, а не только дифайский. Платформа с 146 000 звёзд GitHub — это просто очень удобный пример, до которого удобно дотянуться.
Что делать
Все четыре «дифайных» CVE закрыты в версии v1.4.2 — она вышла незадолго до публикации отчёта. Обновляться стоит немедленно, особенно тем, кто держит собственные инсталляции для корпоративных клиентов. Правка для PDFium ожидается в следующем релизе — за ним тоже нужно следить. Для тех, кто управляет несколькими развёртываниями Dify в контейнерах, исследователи отдельно подчёркивают: обычные сканеры уязвимостей не всегда понимают, что внутри образа лежит старый PDFium — эффект «дыр между сборками». Здесь пригодятся инструменты, которые смотрят именно в бинарный состав контейнеров, а не только в манифесты и SBOM на бумаге.
Организациям, использующим Dify в продакшене, имеет смысл отдельно проверить, не остались ли следы чужих LLM-провайдеров трассировки в конфигурациях приложений и не было ли подозрительных превью-обращений к чужим UUID в логах — теоретически эти следы могли оставить недобросовестные клиенты ещё до патча.
Инцидент наглядно показывает, к чему приводит комбинация открытой регистрации, многотенантной архитектуры и ИИ-нагрузки: одна забытая авторизационная проверка превращается в канал для перехвата чатов у соседа по облаку.