КИБЕРБЕЗОПАСНОСТЬ

Уязвимость Langflow используют для кражи ключей OpenAI и AWS

Не менее 360 атак на уязвимость Langflow зафиксировали исследователи: злоумышленники крадут ключи OpenAI, AWS и данные доступа.

✍️ Редакция iTech News | 02.09.2026 | ⏱ 4 мин | Источник: BleepingComputer
👁

Критическая уязвимость Langflow уже ушла из категории «срочно обновитесь» в категорию «вас, возможно, уже проверили на прочность». Исследователи зафиксировали не менее 360 попыток эксплуатации CVE-2026-0768, а цель атак выглядит предсказуемо и неприятно: ключи OpenAI, секреты AWS, токены и административные данные. Для русскоязычных команд, которые собирают AI-сервисы на open source-стеке, это еще одно напоминание, что low-code вокруг LLM отлично ускоряет разработку, но так же быстро расширяет поверхность атаки.

По данным BleepingComputer, проблема затрагивает Langflow 1.4.2 и более ранние версии. Речь идет об unauthenticated remote code execution: атакующему не нужна авторизация, чтобы добиться выполнения произвольного кода с root-привилегиями. Слабое место находится в валидаторе кода в редакторе пользовательских компонентов. Проще говоря, приложение недостаточно проверяет строку, которую получает через параметр code на endpoint validate, а затем исполняет ее как Python-код. Для платформы, которая используется для сборки AI-приложений, агентов, чат-ботов и RAG-сценариев, это почти худший из возможных сценариев: сервер сам хранит доступы к моделям, облаку, базам и внешним API, а злоумышленнику остается только зайти и аккуратно вынести все полезное.

Атаки заметила компания VulnCheck на своих honeypot-системах в Великобритании. Сначала исследователи говорили как минимум о 50 попытках эксплуатации за выходные, при этом основной трафик шел из России. Затем ведущий исследователь VulnCheck Кейтлин Кондон уточнила, что активность выросла до 360 зафиксированных атак на момент публикации. По ее словам, злоумышленник сначала проводит разведку, а затем опрашивает переменные окружения, чтобы достать административные учетные данные или ключи суперпользователя Langflow, секреты AWS и ключи OpenAI API. Отдельно атакующие читают файл /root/.cache/langflow/secret_key, проверяют доступ к .ssh и даже размер .bash_history. Это важная деталь: речь не о шумном «положить сервер», а о прагматичной краже всего, что поможет закрепиться, расширить доступ и монетизировать взлом.

Сама CVE-2026-0768 была раскрыта еще в январе 2026 года, но эксплуатация в дикой природе началась не в вакууме. У Langflow это уже не первый тяжелый эпизод за год, а скорее повторяющийся сюжет. В марте атакующие начали использовать CVE-2026-33017, критическую уязвимость с внедрением кода, примерно через сутки после раскрытия; тогда они запускали Python-скрипты и вытаскивали .env-файлы и базы данных. Затем пошли атаки через CVE-2026-5027, позволявшую записывать произвольные файлы на сервер, и CVE-2026-55255, через которую можно было получать доступ к AI-воркфлоу других пользователей, красть чувствительные данные и доставлять второй этап вредоносной нагрузки. Была и CVE-2026-0770, позволявшая выполнять команды с root-привилегиями и использовать сервер для вытягивания облачных секретов, переменных окружения и метаданных контейнеров. Совсем недавно CISA отдельно предупреждала об эксплуатации CVE-2026-9198 после появления нескольких публичных PoC. Если смотреть на эту цепочку целиком, проблема уже не выглядит как разовый промах в коде: Langflow стал удобной мишенью для тех, кто системно охотится за AI-инфраструктурой.

Для разработчиков и DevOps-команд в этой истории особенно показателен не только сам RCE, но и то, что именно воруют первым делом. В списке интересов атакующих нет ничего экзотического: переменные окружения, API-ключи, root-секреты, SSH-доступ, история команд. То есть компрометация сервера с Langflow почти автоматически превращается в компрометацию окружающей экосистемы. Один удачный запрос может дать доступ к OpenAI-аккаунту, облачной инфраструктуре AWS, внутренним сервисам и, если повезет атакующему, к пайплайнам разработки. Для бизнеса это уже не «дыра в одном open source-инструменте», а потенциальная цепочка инцидентов: утечка данных, лишние расходы на API, несанкционированный запуск облачных ресурсов, боковое перемещение по инфраструктуре и болезненная ротация секретов в ручном режиме. Особенно уязвимы команды, которые разворачивают такие инструменты быстро, для прототипов или внутренних demo-стендов, а потом забывают, что они вообще торчат наружу.

Есть и еще один неприятный штрих. Кондон говорит, что публичных proof-of-concept для CVE-2026-0768 на данный момент неизвестно. На практике это означает, что даже без широко разошедшегося PoC злоумышленники уже нашли рабочий путь эксплуатации. Иными словами, классическая надежда в духе «пока GitHub не завален готовыми эксплойтами, у нас есть время» здесь не работает. Если сервис доступен из интернета и до сих пор сидит на уязвимой версии, расчет на малозаметность или нишевость продукта выглядит слабой стратегией. Тем более что Langflow используется не только энтузиастами, но и вполне взрослыми командами как удобная прослойка между LLM, базами, векторными хранилищами и внешними API.

Практический вывод у этой истории прямолинейный: пользователям Langflow рекомендуют обновиться до версии 1.11.6, где закрыты известные на сегодня уязвимости. Но обновление здесь только начало работы, а не финальная галочка в трекере. Если инстанс был доступен извне, разумно исходить из того, что после эксплуатации у атакующего могли остаться не только украденные ключи, но и дополнительные точки опоры. Поэтому вопрос уже шире конкретной CVE: сколько еще AI-инструментов, которые команды ставят ради скорости экспериментов, живут в инфраструктуре с root-доступом, облачными секретами и минимальным вниманием к базовой гигиене безопасности. Уязвимость Langflow в этом смысле выглядит не исключением, а очень наглядным диагнозом для всего сегмента AI-dev tooling.

Поделиться: Telegram X LinkedIn