Критическая дыра в Langflow (CVE-2026-55255): CISA требует срочно патчить популярный конструктор ИИ-агентов

Один из самых популярных визуальных конструкторов ИИ-агентов — Langflow — оказался в центре крупного инцидента безопасности. В первую неделю июля 2026 года американское агентство по кибербезопасности CISA внесло уязвимость CVE-2026-55255 в свой каталог KEV (Known Exploited Vulnerabilities — перечень уязвимостей, которые уже эксплуатируются в реальных атаках) и обязало федеральные ведомства США закрыть дыру буквально за считанные дни. Разберём, что именно сломалось, как это используют злоумышленники и почему история важна далеко за пределами госсектора.

Что произошло

Langflow — это низкокодовая (low-code, «почти без программирования») платформа, в которой ИИ-агентов и цепочки обработки данных собирают мышкой из блоков: подключают языковые модели, инструменты, базы знаний и API. Именно из-за такой наглядности Langflow широко используют и стартапы, и корпоративные команды для быстрой сборки прототипов и внутренних сервисов на базе больших языковых моделей.

Обнаруженная уязвимость относится к классу IDOR (Insecure Direct Object Reference — небезопасная прямая ссылка на объект). Проще говоря, приложение доверяет идентификатору, который присылает пользователь, и по нему выдаёт данные, не проверяя, а имеет ли этот пользователь право их получить. В результате авторизованный, но посторонний пользователь может добраться до чужих ресурсов, просто зная их внутренний идентификатор.

Проблема тем серьёзнее, что затрагивает не абстрактные записи, а целые рабочие процессы ИИ-агентов — вместе со всем, что в них зашито: ключами доступа, подключёнными сервисами и обрабатываемыми данными.

В чём суть уязвимости

Корень проблемы — в эндпоинте /api/v1/responses и вспомогательной функции get_flow_by_id_or_endpoint_name. Когда «поток» (flow — так в Langflow называют собранную цепочку/агента) запрашивают по его UUID, код обращается к базе напрямую и не проверяет владельца ресурса. Любопытная деталь: при обращении по текстовому имени эндпоинта проверка прав как раз выполнялась, а вот ветка с UUID её пропускала. Достаточно было подставить идентификатор чужого потока — и система послушно его выполняла.

На практике это означает, что аутентифицированный злоумышленник (например, зарегистрировавшийся в общедоступном или корпоративном экземпляре Langflow) мог:

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

Уязвимость устранена в версии Langflow 1.9.1: в ней проверка владельца добавлена в обе ветки — и для UUID, и для имени эндпоинта. Причём при попытке обратиться к чужому потоку сервер теперь возвращает 404 вместо 403 — чтобы не подтверждать даже сам факт существования ресурса. Все версии до 1.9.1 считаются уязвимыми.

Как это эксплуатируют в реальных атаках

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

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

Почему высокий CVSS — не главное

Вокруг оценки этой уязвимости есть любопытный нюанс. Разные базы данных присваивают ей разный балл CVSS (Common Vulnerability Scoring System — стандартная шкала критичности): от умеренных значений порядка шести баллов в одних источниках до 9.9 из 10 (критическая) в GitHub Advisory. И это хороший повод напомнить: числовой рейтинг и реальная опасность — не одно и то же.

Исследователи безопасности отдельно подчёркивают: далеко не всегда самыми эксплуатируемыми оказываются уязвимости с максимальным CVSS. Решает не формальная оценка, а сочетание факторов — насколько просто атаку автоматизировать, насколько распространён продукт и что именно можно украсть. CVE-2026-55255 закрывает не сервер целиком, но открывает прямой путь к ключам и деньгам — и потому в реальном мире оказалась опаснее многих «десяток». Попадание в каталог KEV — это как раз сигнал «уже эксплуатируется», который важнее любого балла на бумаге.

Связь с автономными атаками ИИ-агентов

История с Langflow тревожна ещё и потому, что вписывается в свежий тренд — атаки, которые ведут сами ИИ-агенты. Ранее в 2026 году исследователи описали кампанию вымогательского ПО под названием JADEPUFFER, где оператор фактически поручил всю операцию автономному агенту: тот сам разворачивал инфраструктуру, крал учётные данные, перемещался по сети и шифровал данные. Отправной точкой в той истории служила другая брешь в Langflow — CVE-2025-3248.

Иными словами, платформы для сборки ИI-агентов сами становятся привлекательной мишенью: они концентрируют в одном месте ключи, доступы и логику автоматизации, а значит, одна ошибка контроля доступа даёт атакующему сразу и «мозги», и «руки». Langflow тут — не единственный пример, а показательный: чем удобнее инструмент склеивает сервисы, тем дороже стоит его взлом.

Что делать прямо сейчас

Если вы или ваша команда используете Langflow — в проде, для внутренних инструментов или даже «на поиграться» на публичном сервере, — стоит действовать не откладывая:

Обновиться

Установите Langflow 1.9.1 или новее — это устраняет саму уязвимость. Обновление первично: всё остальное имеет смысл только после закрытия дыры.

Ротировать ключи

Исходите из того, что все секреты, которые хранились в потоках уязвимого экземпляра, могли утечь. Перевыпустите ключи LLM-провайдеров, токены облачных платформ и прочие учётные данные, а старые — отзовите.

Ограничить доступ

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

Проверить логи

Просмотрите обращения к /api/v1/responses и всплески неожиданного расхода токенов или облачных ресурсов — это может указывать на уже случившуюся эксплуатацию.

Почему это важно для разработчиков и владельцев сайтов

Даже если вы не пользуетесь Langflow напрямую, вывод универсален. Инструменты, которые «в пару кликов» соединяют модели, API и данные, снимают рутину — но одновременно превращаются в единую точку хранения самых чувствительных секретов проекта. Ключи от языковых моделей и облака сегодня — это буквально доступ к деньгам: чужие токены мгновенно конвертируются в счета за API и облачные вычисления.

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