Код, который должен проверять других, сам стал лазейкой для хакеров — что не так с Langflow?
Проверка кода — святое, особенно, когда проверяющий сразу его исполняет.
Критическая уязвимость в платформе Langflow, предназначенной для визуального проектирования цепочек LLM, активно используется злоумышленниками. Проблема получила идентификатор CVE-2025-3248 и оценку 9,8 балла по шкале CVSS — почти максимум.
Уязвимость связана с отсутствием аутентификации при обращении к эндпоинту /api/v1/validate/code, который позволяет удалённым атакующим выполнять произвольный код через специально сформированные HTTP-запросы. Внутри используется функция exec() из Python, и она вызывается напрямую на пользовательском вводе без каких-либо защитных механизмов — ни аутентификации, ни песочницы. Это открывает прямой путь к захвату сервера.
Уязвимость присутствует почти во всех версиях Langflow, за исключением версии 1.3.0 , выпущенной 31 марта 2025 года. Именно в этой версии была реализована защита, устраняющая опасный механизм. Уязвимость была раскрыта в феврале. Ситуация усугубилась 9 апреля, когда в открытом доступе появился рабочий PoC-эксплойт.
По данным платформы Censys, в интернете сейчас находятся 466 открытых экземпляров Langflow, причём большинство из них расположены в США, Германии, Сингапуре, Индии и Китае. Пока неизвестно, кто именно стоит за атаками и каковы их цели, но масштабы угрозы вызывают беспокойство.
Специалисты Zscaler подчёркивают, что случай с CVE-2025-3248 — это наглядное подтверждение того, насколько опасным может быть выполнение пользовательского кода без строгой аутентификации и изоляции. Программистские удобства валидации кода, особенно в веб-приложениях с публичным доступом, требуют осторожности и продуманной архитектуры.
Langflow — популярная в AI-среде платформа с открытым исходным кодом, позволяющая визуально собирать цепочки обработки текстов и запросов с использованием языковых моделей. Уязвимость ударила именно по этой логике, превращая удобство настройки в оружие в руках злоумышленников.
Краткое содержание инцидента заставляет задуматься об архитектуре подобных решений и необходимости использовать проверенные методы защиты, особенно если речь идёт об инструментах, взаимодействующих с исполняемым кодом.