Langflow CVE-2026-0768: 12-я уязвимость Langflow, эксплуатируемая в реальных атаках в этом году

CVE-2026-0768 — это не требующая аутентификации уязвимость удаленного выполнения кода в Langflow, открытом визуальном фреймворке для сборки конвейеров и агентов на основе больших языковых моделей, и к концу августа 2026 года злоумышленники уже использовали ее в реальных атаках. Уязвимость находится в валидаторе кода, который стоит за редактором пользовательских компонентов Langflow: эндпоинт validate принимает параметр code и выполняет содержащийся в нем Python без аутентификации и, по формулировке Zero Day Initiative, «в контексте root». Сеть ханипотов Canary от VulnCheck зафиксировала более 50 попыток эксплуатации в течение нескольких часов после первых обнаружений 30 августа 2026 года и более 360 к понедельнику 1 сентября — все против датчиков в Соединенном Королевстве; Кейтлин Кондон из VulnCheck сказала, что трафик источников в основном шел из России. Эти запросы не были связаны с программами-вымогателями. Они считывали переменные среды, содержащие учетные данные суперпользователя Langflow, ключи API OpenAI, а также ключи доступа и секретные ключи AWS, а затем просматривали /root/.cache/langflow/secret_key, .ssh и .bash_history. Полная запись об этом инциденте в архиве, включая классификации серьезности, уверенности и ущерба, находится в Архиве инцидентов Orca AI, рядом с другими записями о краже учетных данных и инфраструктуре ИИ, которые его окружают.

Security Affairs опубликовала свой материал 2 сентября 2026 года; Ionut Arghire из SecurityWeek сообщил об эксплуатации за день до этого, Bill Toulas из BleepingComputer освещал эту тему на той неделе, а AI Safety Initiative при Cloud Security Alliance 4 сентября последовала с исследовательской заметкой, в которой повторно излагается механизм и добавляются рекомендации. Ни в одном из материалов, рассмотренных для этой статьи, не была названа скомпрометированная организация. Все восходит к собственным сенсорам VulnCheck и к бюллетеню, опубликованному Zero Day Initiative в январе.

Редактор, который выполняет то, что его просят проверить

Ключевое преимущество Langflow в том, что вы собираете ИИ-приложение, перетаскивая компоненты на холст. Пользовательские компоненты написаны на Python: редактор позволяет пользователю вставить код и нажать validate, а сервер проверяет его. Согласно рекомендации ZDI ZDI-26-034, эта проверка выполняет код. Фраза о первопричине в рекомендации состоит из одной строки — «отсутствие надлежащей проверки предоставленной пользователем строки перед её использованием для выполнения кода Python», — а результат таков: один неаутентифицированный HTTP-запрос выполняет произвольный код Python на хосте.

Три свойства превращают это в инцидент, а не в отчёт об ошибке. Вектор CVSS — AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, оценка 9,8: доступен по сети, низкая сложность, отсутствие привилегий, отсутствие взаимодействия с пользователем и полная потеря конфиденциальности, целостности и доступности. Контекст выполнения — root, поэтому команды атакующего, которые описывают и Condon, и Cloud Security Alliance, направлены на /root/.cache/langflow/secret_key — файл, который Langflow использует для шифрования хранимых учётных данных и данных сеансов. И эндпоинт вообще не запрашивает учётные данные, поэтому подверженность определяется исключительно доступностью.

История раскрытия важна для того, как разворачивались события. Хронология ZDI фиксирует, что сообщение поступило в аккаунт Langflow на GitHub 18 июля 2025 года, запрос обновлений — 11 сентября 2025 года, запрос исправления — 10 октября 2025 года, а уведомление о намерении опубликовать как zero-day — 10 декабря 2025 года. ZDI выпустила рекомендацию 9 января 2026 года. Указанные исследователи — Peter Girnus, William Gamazo Sanchez и Alfredo Oliveira из Trend Research. База данных рекомендаций GitHub содержит тот же текст под идентификатором GHSA-x5pr-rvjj-j6qm, опубликована 23 января 2026 года, классифицирована как CWE-94 и вообще не указывает диапазон затронутых версий. Заявленная ZDI мера смягчения — не патч: это «ограничить взаимодействие с продуктом».

В публичных сообщениях уязвимый диапазон относится к выпускам Langflow до версии 1.4.2 включительно — это версия, против которой был собран и протестирован модуль Metasploit, добавленный позже. На этом определённость заканчивается, и раздел об исправлениях ниже объясняет почему.

Что 360-детекции устанавливают, а что — нет

«Канарейки» VulnCheck — это подключённые к интернету сенсоры, созданные так, чтобы выглядеть как то, что ищет сканирующий атакующий. Компания впервые зафиксировала эксплуатацию CVE-2026-0768 29–30 августа 2026 года: более 50 детектирований за несколько часов в воскресенье, а к понедельнику их число превысило 360. Кондон, вице-президент VulnCheck по исследованиям угроз, описал эту активность в LinkedIn как «сочетание разведки и сбора учётных данных», добавив, что исходный трафик в основном шёл из России и «на данный момент затронул исключительно „канареек“ в Великобритании».

Последовательность команд, зафиксированная сенсорами, достаточно конкретна, чтобы служить готовым сценарием. Злоумышленники проверяли окружение на наличие LANGFLOW_SUPERUSER, переменных, соответствующих OPENAI_API, и ключей AWS_ACCESS и AWS_SECRET — трёх семейств учётных данных, которые чаще всего могут храниться на хосте Langflow. Они прочитали кэшированный секретный ключ по пути /root/.cache/langflow/secret_key. Они проверяли доступ к .ssh и изучали размер .bash_history — оба действия указывают на то, может ли оператор перемещаться вбок, а не только читать секреты. В публикации сообщества об этой цепочке, на которую ссылается Cloud Security Alliance, добавляется, что та же активность искала встроенные секреты в деревьях исходного кода и файлах .env, вывозила найденное и проверяла, не установил ли уже бэкдор на хост предыдущий оператор, прежде чем добавить собственный механизм закрепления.

То, что это устанавливает: эксплойт работает, его применяли против доступных из интернета экземпляров Langflow, и целью были учётные данные, а не нарушение работы. Чего это не устанавливает — наличия жертвы. Канарейки — это приманки; обнаружение — это запрос, а не подтверждённая кража. Архив классифицирует эту запись как реальный вред, и задокументированный в публичных источниках вред — это подтверждённое выполнение кода для сбора учётных данных на открытых системах, а не названная организация, чьи ключи были использованы.

Одна деталь противоречит обычной версии событий вокруг раскрытия уязвимости. По данным VulnCheck, на момент начала эксплуатации публичного proof-of-concept для CVE-2026-0768 не существовало. Уведомление было общедоступно почти восемь месяцев и описывало уязвимость достаточно точно, чтобы по его тексту можно было создать эксплойт. По мнению компании, как сообщает The Hacker News, это была независимая разработка, а не повторное использование утёкшего кода.

Двенадцать изъянов, пятнадцать тысяч попыток — и где эти числа дают сбой

Статистика, придающая этому инциденту вес, исходит от VulnCheck, и её стоит процитировать словами самой фирмы, а не пересказывать. «До 2026 года свидетельства показывали только одну уязвимость Langflow, известную как эксплуатируемую в реальных условиях», — говорится в сообщении. «В 2026 году всё быстро изменилось». SecurityWeek сообщает, что VulnCheck отслеживает «11 дополнительных уязвимостей, которые стали целями и были заявлены как эксплуатируемые в реальных условиях» в течение 2026 года.

Добавьте их, и получится двенадцать эксплуатировавшихся уязвимостей Langflow, одна из которых появилась до этого года. Это не то же самое, что двенадцать в 2026 году, и источники колеблются между этими двумя формулировками. Заголовок Forkast называет CVE-2026-0768 «12-й эксплуатируемой CVE Langflow в 2026 году», тогда как в тексте той же статьи эта дюжина описывается как «11 новых уязвимостей и одна, выявленная до начала года». Название записи повторяет заголовок. При строгом прочтении на 2026 год приходится одиннадцать из двенадцати, а двенадцатая — та, что была известна до этого года, — составляет остаток.

Цифра в 15 000 имеет сопоставимый перевес. SecurityWeek, The Hacker News и Forkast все приписывают «более 15 000 успешных атак» трём названным уязвимостям: CVE-2026-0769, CVE-2025-3248 и CVE-2026-5027. Это большое число, но это подсчёт по трём CVE, а не по всему портфелю Langflow за 2026 год. Формулировка этого как попыток эксплуатации против портфеля — как это делает сводка архива — шире того, что опубликовала VulnCheck.

Отдельные случаи, стоящие за этой закономерностью, задокументированы. CVE-2025-3248 представляла собой уязвимость внедрения кода в той же конечной точке /api/v1/validate/code, исправленную в Langflow 1.3.0 путем замены выполнения на проверку только на этапе компиляции, согласно рекомендации GitHub GHSA-rvqx-wpfh-mfx7, на которую ссылается Cloud Security Alliance, — а значит, CVE-2026-0768 относится к тому же классу ошибок в том же пути кода, примерно через четыре месяца после выпуска того исправления. CVE-2026-33017, неаутентифицированное RCE в публичной конечной точке сборки потока, была задействована в атаках примерно в течение 20 часов после раскрытия в марте 2026 года и использована для захвата учетных данных OpenAI, Anthropic и AWS, прежде чем переключиться на майнинг Monero, по описанию Cloud Security Alliance. В заметке того же альянса от 12 июня 2026 года рассматривается CVE-2026-5027 — уязвимость обхода пути в конечной точке загрузки файлов, которую исследователи связали с иранской группой MuddyWater, действующей при поддержке государства, а в заметке от 4 сентября зафиксирована CVE-2026-55255 — обход авторизации, позволяющий аутентифицированному пользователю запускать потоки другого пользователя, которая 7 июля 2026 года была добавлена в каталог Known Exploited Vulnerabilities агентства CISA. У этих четырех уязвимостей общая форма: конечная точка, которая либо пропускала аутентификацию, либо пропускала очистку данных, в платформе, чья задача — хранить учетные данные для всего, с чем она взаимодействует.

Почему оркестрационная платформа оправдывает затраченные усилия

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

Оценка Cloud Security Alliance состоит в том, что повторение проблем в четырёх различных подсистемах Langflow в течение одного года — валидаторе кода, публичной конечной точке сборки потоков, загрузке файлов и выполнении рабочих процессов — указывает на системный пробел в инженерии безопасности, а не на череду несвязанных дефектов. Это оценка альянса, представленная в исследовательской записке, а не вывод независимого аудитора, и Langflow публично не отреагировала на неё в рассмотренных здесь материалах.

Что было исправлено, а что всё ещё остаётся неясным

Это самое слабое место в открытых источниках, и стоит точно объяснить почему. В бюллетене ZDI не указана исправленная версия. В записи базы данных Snyk для этой CVE уязвимыми указаны все версии до 1.10.1, и рекомендуется обновление до 1.10.1 или выше. Публичные материалы, включая SecurityWeek и Security Affairs, описывают затронутый диапазон как выпуски до 1.4.2 включительно, но не указывают исправленный выпуск. Cloud Security Alliance отметил 4 сентября, что сопровождающие Langflow не опубликовали отдельный бюллетень по безопасности с упоминанием этой CVE и что трекеры расходятся во мнениях о том, какой выпуск действительно устранил уязвимость, — неоднозначность, которая, по словам альянса, перекликается с более ранним случаем Langflow, когда версия, заявленная как исправленная, оставалась уязвимой.

Langflow действительно выпустил исправления в нужной области и в нужный день. Версия 1.11.6 была опубликована 1 сентября 2026 года — в понедельник, когда количество ханипотов превысило 360, — и в примечаниях к выпуску описан бэкпорт исправлений безопасности, включая «закрытие пробелов в сканировании кода компонентов» и «разрешение аннотаций без выполнения» (pull request 14876). В тот же вечер последовала версия 1.12.0. Дальнейшее укрепление того же пути кода продолжалось и после этого: более поздний pull request под названием «stop validate_code from executing imports» указывает на то, что конечная точка validate всё ещё ужесточалась спустя недели после первой эксплуатации. Ничто из этого не является заявлением вендора о том, что CVE-2026-0768 исправлена в конкретном выпуске, и ничего подобного не было найдено в цитируемых источниках записи.

Что изменилось на стороне атакующего, понятнее. Модуль эксплойта Metasploit для этой уязвимости был создан как pull request 2 сентября 2026 года — в тот же день, когда опубликовался Security Affairs, — и принят 8 октября 2026 года, протестирован на Langflow 1.4.2. Как бы ни обстояло дело с исходным выводом, через шесть недель после начала эксплуатации этой уязвимости для её эксплуатации перестала требоваться самостоятельная работа.

Рекомендуемый Cloud Security Alliance ответ — это последовательность исправления и ротации, а не одно лишь исправление: проверьте работающую версию и перейдите на текущий стабильный выпуск; считайте любой доступный из интернета экземпляр уязвимой версии скомпрометированным, пока не доказано обратное, поскольку наблюдаемая активность представляет собой скрытый сбор данных, а не видимое нарушение работы; и выполните ротацию всех секретов, к которым мог получить доступ экземпляр, — пароля суперпользователя Langflow, ключей API провайдеров, ключей доступа и секретных ключей AWS, а также самого секретного ключа Langflow, заново зашифровав хранимые учетные данные, а не просто заменив файл. Также рекомендуется провести аудит журналов доступа на предмет запросов к эндпоинту validate, проверить authorized_keys на наличие незнакомых ключей SSH и поискать свидетельства того, что предыдущий оператор уже установил бэкдор на хост. Если платформа должна оставаться доступной, предлагается ограничить доступ к эндпоинту validate или отключить его, а также отказаться от долгоживущих ключей с высокими привилегиями, хранящихся непосредственно в платформе.

Установлено, заявлено и не установлено

Установлено следующее: что CVE-2026-0768 — это неаутентифицированное RCE в конечной точке validate Langflow, выполняющее Python от имени root, задокументированное в ZDI-26-034 и зеркально отражённое как GHSA-x5pr-rvjj-j6qm; что эксплуатация началась 29–30 августа 2026 года; что VulnCheck зафиксировала более 50 обнаружений за несколько часов и более 360 к 1 сентября на британских сенсорах, причём трафик шёл преимущественно из России; и что наблюдаемые запросы были нацелены на учётные данные суперпользователя Langflow, OpenAI и AWS, а также на кэшированный секретный ключ, .ssh и .bash_history. Они взяты из самого уведомления и из телеметрии VulnCheck, о которой независимо сообщили SecurityWeek, Security Affairs и The Hacker News.

Сообщается, но независимо не проверено:все данные о количестве обнаружений. Цифры 50, 360 и 15 000 — это собственные данные VulnCheck, опубликованные фирмой и повторённые изданиями, которые на неё ссылаются; ни одна другая сеть ханипотов не опубликовала подтверждающую цифру. Атрибуция к российской инфраструктуре также является трактовкой VulnCheck трафика источников, а не оценкой, которую какое-либо правительство или CERT поддержало в рассмотренных материалах.

Не установлено: что какая-либо названная организация утратила учётные данные. Ни один пострадавший не выявлен в источниках записи. Также нет подтверждённой исправленной версии: ZDI не называет ни одной, Snyk указывает 1.10.1, в сообщениях говорится, что затронуты версии вплоть до 1.4.2, а примечания к выпуску 1.11.6 описывают исправления безопасности, не связывая их с этой CVE. Кроме того, утверждение о том, что это «двенадцатая уязвимость 2026 года», не является внутренне согласованным в собственных источниках, как изложено выше.

Та часть, которая должна беспокоить людей, устанавливающих патчи по расписанию.

Сам восьмимесячный разрыв и есть главная находка. CVE-2026-0768 была опубликована как zero-day 9 января 2026 года вместе с техническим описанием, достаточно подробным, чтобы воссоздать эксплойт, — и до последних выходных августа против сенсоров VulnCheck не произошло ровно ничего. А затем за три дня пришло несколько сотен попыток — от операторов, у которых, по словам компании, не было публичного эксплойта, который можно было бы скопировать. Что бы ни оставляло эти экземпляры неисправленными на протяжении восьми месяцев после публикации открытого критического бюллетеня, это же самое сделало уязвимость достойной эксплуатации, когда кто-то наконец написал код.

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