В приложении для создания ИИ, которому доверяет ваша команда, обнаружена бэкдор на уровне ядра.

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

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

29 августа 2026 года команда VulnCheck по анализу угроз начала наблюдать непрерывные попытки эксплуатации уязвимых экземпляров Langflow, доступных в интернете. Эксплуатируемая уязвимость — CVE-2026-0768 с оценкой CVSS 9,8 — находилась в кодовой базе Langflow еще до ее публичного раскрытия в январе 2026 года как уязвимость нулевого дня. Эксплуатация, начавшаяся в конце августа, не замедлилась.

Что на самом деле делает уязвимость

Редактор пользовательских компонентов Langflow включает конечную точку проверки (validate endpoint) — функцию, позволяющую разработчикам тестировать фрагмент кода перед добавлением его в рабочий процесс. Идея разумная: предоставить пользователям способ проверить свою логику перед ее выполнением в производственной среде. Проблема в реализации.

Эта конечная точка принимает любой код, отправленный пользователем, и передает его непосредственно в функцию exec() языка Python. Перед выполнением не проводится никакой проверки входных данных, а во многих стандартных конфигурациях для доступа к конечной точке вообще не требуется аутентификация. Злоумышленник, который может получить доступ к экземпляру Langflow, доступному из интернета, может отправить специально сформированный запрос на эту конечную точку и немедленно выполнить произвольный код Python — от имени root, без учетных данных и без какого-либо взаимодействия с пользователем.

Попав внутрь, цепочка атак развивается быстро и последовательно. Злоумышленники ищут файлы .env, переменные окружения, SSH-ключи и исходный код. Они извлекают ключи API OpenAI, учетные данные AWS, токены облачного хранилища и учетные данные баз данных. Эти украденные учетные данные отправляются на внешнюю инфраструктуру, и злоумышленник пытается осуществить боковое перемещение через SSH и другие протоколы. Вся последовательность — от первоначальной эксплуатации до кражи учетных данных — оставляет мало следов во время обычной активности рабочего процесса ИИ, что значительно затрудняет обнаружение.

VulnCheck зафиксировал более 360 попыток эксплуатации на своих британских honeypot-системах в дни после публичного раскрытия, причем большая часть трафика атак исходила из России. Это число отражает наблюдаемые попытки против инструментированных систем. Количество успешных атак на неинструментированные производственные развертывания неизвестно.

Почему это становится закономерностью

Уязвимость Langflow не возникла изолированно. До 2026 года в реальных условиях была успешно использована только одна уязвимость Langflow. В этом году их число возросло до двенадцати. VulnCheck зафиксировал более 15 000 успешных попыток эксплуатации трех связанных уязвимостей Langflow — CVE-2026-0769, CVE-2025-3248 и CVE-2026-5027 — до того, как к этому списку добавилась CVE-2026-0768.

Причина не в том, что Langflow внезапно стал менее безопасным. Причина в том, что Langflow стал достаточно ценным, чтобы на него нападать. Как написали исследователи VulnCheck, быстрое внедрение технологий ИИ привело к появлению инструментов, разработчики которых ставили доступность выше принципов безопасности. Те же качества, которые делают платформы для разработки ИИ привлекательными для корпоративных команд — доступность с открытым исходным кодом, простота развертывания, широкие интеграции API, подключения к облачным сервисам и ИИ-аккаунтам — делают их привлекательными целями, как только появляется примитив выполнения кода.

Это та же динамика, которая наблюдалась с платформами CI/CD, затем с инструментами управления Kubernetes, а теперь с инфраструктурой разработки ИИ. Категория инструментов быстро растет, проверка безопасности отстает, и злоумышленники вторгаются, как только установленная база становится достаточно большой, чтобы стоить усилий.

Экземпляр Langflow, доступный из интернета, с неустраненной CVE-2026-0768 — это не столько проблема Langflow. Это проблема утечки учетных данных. Ключ API OpenAI, украденный из файла .env разработчика, не заботится о том, как он был получен. Учетные данные AWS, извлеченные из переменной окружения, не истекают, когда патч в конечном итоге будет применен. Уязвимость Rails, раскрытая вместе с этим исследованием, ясно демонстрирует это: скомпрометированный секрет остается полезным до тех пор, пока не будет заменен, независимо от того, была ли исправлена уязвимость, которая его раскрыла.

Три важные меры контроля прямо сейчас

1. Немедленно установите патч и определите все уязвимые экземпляры. Затронуты все версии Langflow до 1.4.2 включительно. VulnCheck начал наблюдать попытки эксплуатации в течение нескольких часов после публичного раскрытия — окно между появлением патча и сканированием злоумышленниками неотлаженных экземпляров измеряется часами, а не днями. Любое развертывание Langflow, доступное из интернета без аутентификации перед конечной точкой проверки, представляет собой активный риск прямо сейчас. Первый шаг — узнать, сколько экземпляров существует в вашей среде и какие из них доступны из интернета. Многие организации обнаруживают во время инцидентов, что среды разработки и тестирования были доступны без ведома команды безопасности.
2. Замените все учетные данные, которые имели доступ к уязвимым экземплярам Langflow. Это не опция, даже если вы считаете, что ваш экземпляр не был активно использован. Цепочка атак нацелена на файлы .env, переменные окружения, SSH-ключи и облачные учетные данные — элементы, которые сохраняются на диске и в памяти во время обычной работы Langflow. Ключ API OpenAI или учетные данные доступа AWS, хранящиеся в среде, где использовалась уязвимая версия Langflow, следует считать потенциально скомпрометированными. Замените их. Просмотрите журналы доступа на стороне поставщика учетных данных на предмет запросов, которые не инициировал законный владелец. Руководство VulnCheck конкретно указывает на учетные данные OpenAI и AWS как на основные цели наблюдаемой кампании, и замена учетных данных — это единственный контроль, который остается эффективным независимо от того, произошла ли эксплуатация.
3. Не открывайте платформы разработки ИИ в интернете без аутентификации. Отсутствие аутентификации в конечной точке проверки Langflow в стандартных конфигурациях является прямой причиной этой атаки. Но принцип шире: платформы для разработки ИИ, инструменты автоматизации рабочих процессов и среды разработки агентов не являются потребительскими сервисами. Они подключаются к производственным учетным данным, облачным аккаунтам и внутренним API. Развертывание их с конечными точками, доступными из интернета, и без уровня аутентификации эквивалентно предоставлению доступа к базе данных разработки через общедоступный интернет. Размещайте эти развертывания за VPN или требуйте аутентификацию на периметре сети. Применяйте те же элементы управления доступом, которые вы применяли бы к любой другой внутренней инфраструктуре разработки.

Честная оценка

Уязвимость CVE-2026-0768 в Langflow серьезна, но более значимой является траектория, которую она представляет. Двенадцать уязвимостей Langflow, использованных в 2026 году, по сравнению с одной за все предыдущие годы, — это не совпадение. Это сигнал о том, что злоумышленники методично работают через стек инструментов ИИ, так же, как они работали через инструменты управления облаком и конвейеры разработчиков в предыдущие годы.

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

CVE-2026-0768 исправлена, и исправление доступно. Учетные данные, украденные между 29 августа и моментом, когда ваша организация установит патч и заменит учетные данные, — это другая проблема. Для нее нет обновления от поставщика.