CVE-2025-34291: Уязвимость захвата учетной записи и удаленного выполнения кода в Langflow AI Intelligence Body and Workflow Platform

1. Фон

Жетон может открыть двери для вас или того, кто его держит.

недавноСалеслофт-ДрифтЭтот инцидент показывает, какой ущерб могут нанести подобные атаки. Злоумышленник UNC6395 использовал украденные токены OAuth для масштабной кражи данных примерно 700 организаций Salesforce, включая такие крупные технологические компании, как Cloudflare, Zscaler и Palo Alto Networks.

ИИ代理和工作流平台已成为外部服务和数据系统的集成中心。每次集成都会增加更多凭证，将敏感访问权限集中在一处。这种集中化使得攻击者成为高价值目标：一次安全漏洞就可能让攻击者获得所有连接系统的“主密钥”。

В случае с общими платформами одна брешь в системе безопасности может затронуть несколько организаций; в случае с самостоятельными платформами одна брешь в системе безопасности может затронуть несколько сервисов в рамках одной организации. Учитывая эти риски, мы провели оценку безопасности ряда известных агентов ИИ с открытым исходным кодом и платформ документооборота, чтобы выявить потенциальные уязвимости, которые могут привести к полному разрушению базовой системы.

В качестве основного объекта исследования мы выбрали Langflow - фреймворк визуализации с открытым исходным кодом для создания рабочих процессов ИИ, приложений RAG и мультиинтеллектуальных систем с более чем 140 000 звезд на GitHub.Построенный на Python и FastAPI, Langflow Langflow построен на Python и FastAPI и предоставляет интуитивно понятный drag-and-drop интерфейс, который позволяет разработчикам создавать сложные приложения для ИИ без написания большого количества кода.

‍

‍

Примечательно, что в апреле 2024 года Langflow была приобретена компанией DataStax, которую в настоящее время приобретает IBM (объявлено в феврале 2025 года), что делает Langflow частью расширяющегося портфолио IBM Watsonx AI.

2、 Анализ и применение глубины лангетного потока

2.1, CVE-2025-3248: два года истории

Langflow - молодой и быстро итерируемый проект - именно тот тип проектов, который заслуживает более глубокого изучения его безопасности. Хорошей отправной точкой является история его уязвимостей. Всего несколько месяцев назад всплыла уязвимость CVE-2025-3248: серьезная уязвимость удаленного выполнения кода без аутентификации, затрагивающая версии до 1.3.0.

Поражает не только серьезность проблемы, но и история ее возникновения: почти два года с момента обнаружения до окончательного исправления - необычайно долгий период времени, который раскрывает архитектурные компромиссы и то, как развивалась система безопасности Langflow.

График обнаружения и устранения последствий:

• 27 июля 2023 года: Пользователь GitHub @Lyutoon представил проблему #696Отмечается, что неаутентифицированные конечные точки проверки кода могут быть использованы для удаленного выполнения кода (Remote Code Execution, RCE) через параметры по умолчанию в определениях функций.
• 10 ноября 2024 года: Пользователь Github @nimasteryang подал запрос на вытягивание #4488Компания попыталась устранить уязвимость, но от исправления отказалась, поскольку оно нарушило бы существующую функциональность.
• 22 февраля 2025 г. Horizon3.aiИсследователи безопасности сообщили об уязвимости в Langflow через GitHub Security Issues, обнаружив второй, другой вектор RCE, использующий декоратор функций для запуска RCE во время проверки кода.
• Письмо от 3 марта 2025 года от Постоянного представителя: Команда Langflow об уязвимых конечных точках#6911Внедрите требования к аутентификации, чтобы официально устранить уязвимость CVE-2025-3248.

Хронология последних двух лет показывает знакомый компромисс: особенно в области искусственного интеллекта, команды пытаются создать и завоевать признание, в то время как безопасность остается позади.

2.2. Уязвимости: краткий обзор

Давайте вкратце рассмотрим, как работает эта уязвимость.

Основная проблема связана с тем, что Langflow/api/v1/validate/codeИнтерфейс, предназначенный для аутентификации фрагментов кода Python для пользовательских компонентов. Однако до версии 1.3.0 доступ к этому интерфейсу можно было получить без какой-либо аутентификации:

src/backend/base/langflow/api/v1/validate.py

‍

долженvalidate_code()Функция анализирует предоставленный код, проверяет, содержит ли он определения функций, а затем выполняет эти функции для их проверки:

src/backend/base/langflow/utils/validate.py

Этот код предполагает, что определения функций безопасны для выполнения. Это не так. Когда функция `exec()` выполняет определение функции, она сразу же выполняет аргументы по умолчанию и выражение в декораторе.

‍

Без механизма "песочницы" любой неаутентифицированный пользователь может полностью скомпрометировать систему, отправив POST-запрос на сервер/api/v1/validate/code.

Эта уязвимость активно эксплуатируется угрожающими субъектами, развертывающими ботнет Flodric через скомпрометированные экземпляры Langflow.Исследование Trend MicroЭто было записано.

3. От открытости к закрытости

В ответ на CVE-2025-3248 мы добавили функцию аутентификации в конечную точку /api/v1/validate/code. Когда запрос достигает этой конечной точки, механизм инъекции зависимостей FastAPI автоматически запускает процесс аутентификации.

3.1. Требования к аутентификации конечных точек

‍

3.2. Убедитесь, что учетная запись пользователя активна

‍

3.3. Выполните проверку физической аутентификации

Функция get_current_user() проверяет оба источника аутентификации в порядке приоритета:

в первую очередь: JWT-токен из заголовка Authorization: Bearer .

второй тип: ключ API из заголовка x-api-key или параметра запроса

После выхода исправления конечная точка проверки кода больше не открыта по умолчанию. Для доступа к этой конечной точке теперь требуется действительный токен JWT или действительный ключ API.‍

4. От защиты к утечке:CVE-2025-34291

В теории аутентификация выглядит идеально. Поэтому на практике возникает вопрос: можем ли мы получить доступ к действительным учетным данным или использовать их? Интерес представляют следующие три области:

1) Ключ API

Прогноз тревожный. Ключ API не настраивается автоматически по умолчанию и должен быть явно создан пользователем в настройках. Ограниченная поверхность атаки.

2) CSRF и CORS?

Это интересный путь. Без надлежащей защиты CSRF злоумышленник можетмежсайтовая записьВыполните запрос от имени пользователя. Если политика CORS настроена неверно, злоумышленник может выполнить и другие действияперекрестное чтениечтобы получить чувствительный ответ, возвращенный аутентифицированным запросом.

3) Кража токенов JWT с помощью XSS

Бэкэнд генерирует и подписывает JWT (HS256) во время входа в систему, а затем устанавливает его как часть HTTP-ответа наaccess_token_lfпеченьеSameSite=Lax. Этот же маркер включается в тело ответа.

Затем внешний модуль считывает этот cookie и использует стандартныйАвторизация: Bearerзаголовок включает этот токен во все запросы к API.

Другими словами, значение JWT-токена совпадает со значениемaccess_token_lfЗначение, хранящееся в файле cookie, остается прежним. Поскольку файлы cookie не шифруютсяHttpOnlyПоэтому JavaScript на стороне клиента может прочитать его - но для этого требуется отдельная XSS-уязвимость в Langflow.

К счастью, метод 2 сработал: мы нашли две ошибки в конфигурации, которые вместе полностью обходили аутентификацию.

4.1. Неправильная конфигурация CORS

По умолчанию Langflow использует CORSMiddleware от FastAPI со свободными настройками, чтобы разрешить запросы из любого источника. В дополнение к этомуразрешить_учетные данныеЭтот параметр также имеет значение True, чтобы позволить злоумышленнику инициировать междоменные запросы с использованием учетных данных.

langflow/main.py#L292-L300

Однако есть две проблемы, которые мешают дальнейшей эксплуатации:

• Выпуск 1: Cookie для аутентификацииaccess_token_lfнастроенныйSameSite=Laxчто исключает его из большинства межсайтовых контекстов (XHR/fetch/POST), за исключением GET-навигации верхнего уровня, инициированной пользователем.
• Выпуск 2: В Langflow 1.5 и более поздних версиях большинство конечных точек API требуют дополнительной аутентификации - либо путем предоставления ключа API Langflow, либо путем включения JWT-токена в заголовок Authorisation, который не включается автоматически в кросс-доменные запросы.

Поэтому мы не должны иметь возможности отправлять аутентифицированные междоменные запросы. Такая настройка CORS кажется достаточно безобидной - до тех пор, пока упущенная из виду деталь не запустит цепочку атак.

4.2. Ошибка конфигурации куки refresh_token_lf

долженrefresh_token_lfФайлы cookie настроеныSameSite=None; Secureчто делает его доступным в межсайтовом контексте через HTTPS. Кроме того, он действует до недели, что дает злоумышленникам больше возможностей для атаки.

должен/api/v1/refreshКонечная точка полагается только на этот файл cookie как на механизм аутентификации и не реализует никакой дополнительной защиты от CSRF.

В результате междоменный запрос из контролируемого злоумышленником домена/api/v1/refreshНовая пара жетонов может быть успешно получена: жетонaccess_tokenи новый токенrefresh_tokenЭто позволяет полностью перехватить сессию.

‍

Злоумышленник, обладающий действительным маркером доступа, может просто отправить еще один кросс-доменный запрос, чтобы использовать уязвимость CVE-2025-3248 и получить возможность удаленного выполнения кода.

‍

5. этапы воспроизводства

5.1 Параметры окружающей среды

1. Настройте Langflow локально с помощью Docker Compose и включите HTTPS.:

‍
2. Посещение Лангфлоу:https://:443Откройте его в браузере и замените<server-addr>IP/имя хоста сервера, на котором развернут Langflow.

3. Вход: Использовать по умолчаниюadmin:adminУчетные данные для начала нового сеанса пользователя.

5.2 Доказательство концепции

1. откройте страницу PoC: Навигацияhttps://www.pocs.app/langflow-cors-vul-poc.htmlдо

2. Цели конфигурации: Измените базовый URL-адрес назначения, а затем нажмитеЗапуск эксплойта.

3. Свидетельствовать о чудесах: В течение нескольких секунд произойдет следующее:

• POST /api/v1/refreshБраузер отправляет междоменный запрос, содержащий cookie-файл жертвы.
• Извлеченные PoC иaccess_tokenrefresh_token
• Затем он передает/api/v1/validate/codeКонечная точка провоцирует удаленное выполнение кода (Remote Code Execution, RCE).

4. Результаты: Переменные среды или другие конфиденциальные данные будут отображаться на панели терминала PoC.

6. влияние уязвимостей

Langflow использует глобальные переменные для хранения и повторного использования учетных данных и других общих значений в разных процессах. Эти переменные постоянно хранятся во внутренней базе данных, а их значения шифруются с помощью ключей.

Если система взломана, злоумышленнику не составит труда расшифровать эти значения.

Полный перехват сеанса и удаленное выполнение кода - полный контроль над системой может быть достигнут с помощью одного вредоносного посещения веб-сайта. Поскольку запросы инициируются из браузера жертвы через CORS, даже непубличные локально развернутые экземпляры могут быть использованы.

Уязвимости удаленного выполнения кода (RCE) особенно опасны в контексте роли Langflow как агента искусственного интеллекта и платформы для организации рабочего процесса. Злоумышленники могут получить доступ к потокам проектов и привилегированным учетным данным, хранящимся в рабочем пространстве, включая ключи API, пароли баз данных и токены сервисов, используемые для подключения к SaaS, облачным и другим средам. Это значительно расширяет сферу атаки за пределы самого экземпляра Langflow, превращая платформы для создания агентов, такие как Langflow, в единую точку отказа.

6.1 Рекомендации по безопасности

Задержка Langflow с выпуском полного исправления, по-видимому, связана с опасениями, что ужесточение настроек cookie/CORS может нарушить разделение фронт-энда и бэк-энда.

С точки зрения безопасности вопрос заключается в том, как следует защищать конечную точку обновления?

1. если аутентификация основана на куках, необходимо обеспечить соответствующую защиту от CSRF. Для развертывания на одном сайте (например, https://app.example.com → https://api.example.com, который является междоменным, но все еще принадлежит одному сайту), куки refresh можно безопасно использовать с SameSite=Lax или Strict (предпочтительно с включенными Secure и HttpOnly). Если front-end и back-end не находятся на одном сайте Если front-end и back-end не находятся на одном сайте, а некоторые функции требуют SameSite=None, необходимо добавить явный механизм CSRF-токенов.

2. токены обновления предпочтительно отправлять через HTTP-заголовки, а не через cookies. Использование `Authorisation: Bearer ` полностью устраняет модель угрозы CSRF, позволяет избежать вложения учетных данных, управляемых браузером, и упрощает защиту CORS.

И последнее, но не менее важное: уязвимость не была следствием одного критического недостатка, а скорее результатом комбинации безобидных на первый взгляд конфигурационных решений, которые в совокупности создали серьезный путь для атаки. Этот инцидент подчеркивает важный урок: в сложных системах даже безобидные на первый взгляд проектные решения могут взаимодействовать неожиданным образом. Он подчеркивает важность всестороннего анализа безопасности и конфигураций безопасности по умолчанию - особенно по мере того, как платформы искусственного интеллекта все больше внедряются в рабочие процессы предприятий и обрабатывают все более конфиденциальные данные.

6.2 Программа мер по снижению воздействия на окружающую среду

После ответственного раскрытия проблемы команда Langflow признала ее наличие и приступила к ряду исправлений. Согласно журналам разработки Langflow:

• Версия 1.6.0Были введены новые переменные окружения, позволяющие пользователям полностью настроить CORS-конфигурацию Langflow.
• В предстоящем выпуске 1.7Ниже приведены некоторые примеры программ и мероприятий CORS иrefresh_token_lfВсе файлы cookie будут установлены на более безопасные настройки по умолчанию:
  • CORS разрешает только аутентифицированные запросы из явно указанных источников.
  • refresh_token_lfПо умолчанию cookie будет установлен наSameSite=LaxСократите межсайтовое воздействие.

На данный момент последней официальной версией является 1.6.9, и 1-click Remote Code Execution (1-click RCE) по-прежнему полностью доступен с настройками по умолчанию.

Организации могут следоватьОфициальное руководство по CORSВручную улучшите его развертывание. Кроме того, если внешняя и внутренняя части расположены на одном сайте, вы можете применить PR #10139процедуры восстановления вОБНОВИТЬ_ОДИНАКОВЫЙ_САЙТОбновления производятся на уровне исходного кода.StrictLax

Кроме того, команда Langflow работает над конечной точкой проверки кода для#10696Песочница для разработчиков. Надеемся, это позволит раз и навсегда решить проблему потенциального риска удаленного выполнения кода.

6.3. График раскрытия уязвимостей

• 29 июля 2025 г.- Уязвимость была отправлена через GitHub Security Issues; о ней также сообщили DataStax на HackerOne в качестве резервной копии.
• Письмо от 29 июля 2025 года Постоянного представителя--Langflow представил PR #9240("Улучшить безопасность куки"). Это внешнее изменение не влияет на куки httpOnly (которые должны быть настроены на внутреннем сервере), поэтому оно не снимает проблему.
• 31 июля 2025 г.- Сообщения на HackerOne распределены по категориям.
• Письмо от 5 августа 2025 года от Постоянного представителя-Запрос на обновление информации о проблемах безопасности GitHub.
• Письмо от 7 сентября 2025 года от Постоянного представителя-Запрос на обновление информации о проблемах безопасности GitHub.
• 11 сентября 2025 г.- Langflow представила PR #9441("Добавьте переменные окружения для контроля пользователей") и добавили предупреждение о том, что "В версии 1.7 учетные данные будут автоматически отключены при использовании источников с подстановочными знаками".
• 25 сентября 2025 г.-- Выпущен Langflow 1.6.0: введены переменные окружения для настройки разрешенных источников CORS. Однако конфигурация по умолчанию по-прежнему уязвима.
• 26 сентября 2025 г.-Запрос на обновление информации о прогрессе HackerOne.
• Письмо от 3 октября 2025 года от Постоянного представителя-- DataStax ответила: "Это дело команды".
• 22 октября 2025 г.- Информации о безопасности GitHub пока нет; VulnCheck было предложено присвоить номер CVE.
• Письмо от 23 октября 2025 года Постоянного представителя--CVE-2025-34291 Уязвимость была присвоена. Спасибо команде VulnCheck за быструю помощь по CVE.
• 4 ноября 2025 г.--Прошло четыре месяца, и поскольку пользователи могли вручную устранить проблему, изменив конфигурацию CORS, мы решили опубликовать это исследование.

Исследователи безопасности из Obsidian Security обнаружили цепочку серьезных уязвимостей в Langflow.