Критическая уязвимость Langflow с идентификатором CVE-2026-0768 уже эксплуатируется в реальных атаках, а счётчик срабатываний на ловушках VulnCheck быстро перевалил за 50 только за одно утро. Для команд, которые держат Langflow в интернете ради прототипов, агентных пайплайнов и внутренних AI-сервисов, это плохая новость: уязвимость Langflow позволяет не просто «постучаться» в сервер, а получить выполнение кода и добраться до секретов.
Об этом сообщает Dark Reading. Речь идёт о RCE-уязвимости в Langflow, low-code платформе для сборки AI-агентов. Проблема получила 9,8 балла по шкале CVSS, а впервые её публично раскрыли ещё в январе 2026 года через Zero Day Initiative от Trend Micro. Иными словами, окно между публикацией сведений и заметной волной атак оказалось не теоретическим сюжетом для презентаций CISO, а вполне рабочим сценарием: у атакующих было достаточно времени изучить поверхность атаки и подготовить автоматизацию.
Первый публичный сигнал о живой эксплуатации появился 29 августа 2026 года. Вице-президент по исследованию безопасности VulnCheck Кейтлин Кондон написала, что компания увидела более 50 срабатываний на своих canary-системах, то есть на специально выставленных ловушках. По её словам, злоумышленники сочетали разведку с попытками вытаскивать учётные данные. На тот момент активность фиксировалась на британских ловушках, а значительная часть запросов шла с IP-адресов из России. Уже к 1 сентября картина стала шире: VulnCheck наблюдала устойчивую эксплуатацию примерно с 20 разных IP-адресов более чем из полудюжины стран.
Сама механика атак выглядит неприятно знакомо для любой AI-инфраструктуры. Исследователи видели автоматическое сканирование, попытки первичного проникновения, а затем уже постэксплуатационные действия: чтение secret_key у Langflow, поиск API-ключей и облачных credentials в переменных окружения, охоту за SSH-ключами и файлами .env, боковое перемещение и даже эксфильтрацию исходного кода Langflow. Для разработчиков это важная деталь. В 2026 году секреты по-прежнему любят хранить «временно» в env, а временное, как обычно, живёт дольше продакта. Если такой узел ещё и доступен из интернета, уязвимость Langflow превращается из отдельного бага в удобную точку входа в остальную инфраструктуру.
Почему именно Langflow начали трогать чаще
История не ограничивается одним CVE. За несколько дней до нынешней волны VulnCheck выпустила разбор других атак на Langflow, где фигурировали CVE-2025-3248 и CVE-2026-0769. По данным исследователей, за этими эпизодами стояли как минимум два разных актёра с разными целями. Один, судя по наблюдениям, был нацелен на кражу учётных данных с хоста, чтобы двигаться дальше по корпоративной среде. Второй был больше заинтересован в расширении криптомайнинговой активности. Это хороший маркер зрелости угрозы: платформу уже не «щупает» один случайный оператор, её начинают использовать разные группы под разные задачи.
На этом фоне особенно показателен ещё один факт из материала Dark Reading. До 2026 года в дикой природе наблюдали эксплуатацию только одной уязвимости Langflow. За этот год, по данным VulnCheck, таких уязвимостей стало на 11 больше. Для рынка это означает, что Langflow попал в более широкую категорию систем, которые атакующие считают оправданной инвестицией времени. Причина вполне прозаична: корпоративный AI сейчас внедряют быстро, часто поверх старых процессов безопасности, а новые платформы нередко проектируются вокруг скорости разработки, а не вокруг принципа secure by default.
Есть и архитектурная причина. Langflow задуман так, чтобы его разворачивали как доступный по сети сервис. Для разработчика это удобно: визуально собираешь цепочки, подключаешь инструменты, прикручиваешь внешние модели и сервисы. Для атакующего это тоже удобно: в одном месте могут лежать доступ к MCP-серверам, вычислительные ресурсы, чувствительные данные и мосты в другие сегменты корпоративной сети. Если смотреть на это глазами offensive-команды, перед нами не просто ещё одна веб-панель, а концентратор полезных артефактов. Неудивительно, что интерес к таким узлам растёт быстрее, чем у многих более скучных внутренних приложений.
Что это значит для команд разработки и бизнеса
Практический вывод здесь довольно жёсткий. Если Langflow у вас выставлен наружу, рассчитывать на то, что система «малозаметная» и потому никому не интересна, уже нельзя. Кондон прямо говорит: злоумышленники оппортунистически ищут интернет-доступные инсталляции Langflow. Это важный сигнал для российских и русскоязычных команд, у которых AI-эксперименты часто стартуют снизу: сначала внутренний стенд, потом демонстрация бизнесу, потом внезапно этот стенд начинает жить как полупродакшн. Именно в такой фазе обычно забывают поменять ключи по умолчанию, сегментировать сеть, убрать лишние права и вынести секреты из окружения в нормальное хранилище.
Из упомянутых мер защиты нет ничего экзотического, но именно они чаще всего не сделаны. Администраторам рекомендуют минимизировать внешнюю доступность Langflow, не оставлять стандартные secret keys и вводить дополнительные контроли, которые снижают риск произвольного выполнения кода. Переводя с языка advisories на язык операционки: прятать сервис за VPN или хотя бы за жёстким периметром, пересматривать IAM и ротацию ключей, проверять, что лежит в .env, и считать любой интернет-доступный low-code AI-узел потенциальной стартовой площадкой для компрометации облака.
Для отрасли в целом это ещё один холодный душ. AI-платформы долго продавались как способ ускорить разработку и упростить сборку агентных систем. Всё так, но безопасность не исчезает от того, что интерфейс стал drag-and-drop. Скорее наоборот: чем ниже порог входа, тем выше шанс, что критичный сервис развернёт не platform team с паранойей, а команда, которая просто хочет быстро показать результат. Вопрос теперь не в том, будут ли атакующие и дальше разбирать такие инструменты по винтикам, а в том, успеют ли компании перестать относиться к AI-обвязке как к «вспомогательной штуке», которую можно защитить потом.