Хакеры добрались до Langflow — критическая уязвимость открывает root-доступ без авторизации

Критическая дыра в Langflow перестала быть теорией и стала рабочим инструментом атакующих. CVE-2026-0768 получила 9,8 балла по CVSS и даёт удалённое выполнение Python-кода без авторизации, сразу с правами root. VulnCheck зафиксировала рост обращений к тестовым узлам компании с нескольких десятков до 360 с лишним за считанные дни.

Langflow — low-code платформа для сборки AI-агентов и LLM-пайплайнов без ручного кодинга бэкенда. Разработчики тащат туда готовые блоки, соединяют стрелочками и получают рабочего агента за вечер. Для атакующего это лакомый кусок посерьёзнее рядового веб-сервера, рядом с такой платформой обычно лежат токены, API-ключи и доступы к облакам, к которым эти агенты подключены.

После взлома охота идёт по конкретным целям:

• переменные окружения LANGFLOW_SUPERUSER и OPENAI_API;
• доступы AWS_ACCESS и AWS_SECRET;
• файл /root/.cache/langflow/secret_key;
• следы SSH-доступа и сохранённые ключи.

Боты не просто стучатся в дверь, они сразу проверяют, что можно унести.

Технически проблема сидит в механизме проверки кода для пользовательских компонентов. Сервер берёт строку от пользователя и без нормальной фильтрации отправляет её прямиком в исполнение на Python. Аутентификация тут вообще не нужна, запрос летит сразу к уязвимой функции, и через пару секунд у атакующего уже интерактивный доступ с правами root, без пароля, без входа, без вопросов.

Отмечается, что 30 августа зафиксировано более 50 обращений к тестовым узлам, а к началу сентября счёт пошёл на 360 с лишним — для одной дыры это очень резкий разгон.

Специалисты Trend Research сообщили о проблеме команде Langflow ещё 18 июля 2025 года, следом шли запросы о статусе патча. В январе 2026 Zero Day Initiative опубликовала данные об уязвимости как о zero-day, а под ударом остались версии Langflow вплоть до 1.4.2.

Основной поток подозрительных запросов, по данным VulnCheck, шёл из России и упирался в тестовые системы компании в Великобритании — повод присмотреться к своим серверам и российским командам, которые гоняют похожие пайплайны у себя.

Чаще всего уязвимые серверы находили в этих странах:

• США;
• Германии;
• Малайзии;
• Бразилии;
• Индии.

Через CVE-2026-5027 на один из скомпрометированных серверов прилетела программа для кражи учётных данных вместе с прокси-инструментами и SimpleHelp для удалённого доступа, классический набор для закрепления в системе. Через CVE-2025-3248 другой сервер подключили к ботнету для добычи Monero.

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

Список новыми находками не ограничивается:

• CVE-2026-7667 — запись произвольного содержимого через Content-Disposition в IBM Langflow OSS с 1.0.0 по 1.10.0;
• CVE-2026-7700 — удалённое выполнение кода через манипуляции с eval в LambdaFilterComponent, версии Langflow до 1.8.4, эксплойт для неё уже гуляет открыто.

VulnCheck собрала собственный эксплойт для CVE-2026-0768 и добавила его в инструментарий для анализа первоначального доступа. По данным компании, Shodan показывает чуть менее 2500 инстансов Langflow, доступных прямо из интернета, вполне себе поле для автоматического перебора целей. Со стороны обновлённый сервер и уязвимый выглядят одинаково, баннер сервиса не выдаёт номер версии, поэтому просканировать весь этот список и отсеять живые цели занимает у бота от силы пару часов.

Российским командам, которые держат у себя Langflow для внутренних AI-пайплайнов, та же логика применима один в один, старая версия, открытая наружу панель и забытые секреты на диске способны стоить так же дорого, как клиентам где-нибудь в Бразилии или Индии. Из практики для владельцев таких серверов есть несколько конкретных шагов:

• обновиться до пропатченной версии;
• не светить админку Langflow наружу без необходимости;
• перепроверить переменные окружения, API-ключи и SSH-доступы;
• если сервер уже был открыт в уязвимой версии, поднять логи, процессы и сетевые соединения за последние недели.

Немало уязвимых инстансов родились не как боевая инфраструктура, а как эксперимент одного разработчика на свободном сервере. Сначала Langflow поднимают ради прототипа, потом к нему цепляют API-ключи, базы и внешние интеграции, а через полгода забытый тестовый стенд внезапно оказывается частью рабочего продакшена, о патчах для которого никто уже не вспоминает.

Конструктор для AI-агентов оказался заодно и конструктором для root-шелла, если его не патчить и не прятать от интернета. Дальше уже дело техники, искать секреты, закрепляться и ехать дальше по чужой инфраструктуре на нанятой без спроса машине.

Ранее сообщалось, что исследователи обнаружили серьезный дефект в модемной прошивке четырех мобильных платформ Unisoc, который потенциально позволяет получить контроль над бюджетным Android-смартфоном через обычный видеовызов. Проблема затрагивает T612, T616, T606 и T7250 — процессоры, которые используются в устройствах Xiaomi, Motorola, Realme и других производителей. При успешной эксплуатации атакующий получает уровень доступа к ядру, обходя стандартную модель защиты Android.

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

Специалисты CISOCLUB подчеркнули, что от закрытого наружу тестового стенда до продакшена с реальными клиентами часто остаётся один забытый API-ключ на диске. Они уверены, что без регулярного аудита версий и открытых портов компании ещё долго будут находить у себя уязвимые копии Langflow. По их мнению, разрыв между лабораторным PoC и рабочим эксплойтом в 2026 году сократился до считанных недель, и Langflow тут далеко не последний пример. Стоит относиться к любому low-code AI-инструменту как к полноценному production-сервису с первого дня, а не как к внутренней игрушке, которую можно пропатчить как-нибудь потом.