За несколько часов 30 августа исследователи зафиксировали более 50 срабатываний, а к понедельнику их число выросло до 360: в ход пошли критические уязвимости Langflow и Ruby on Rails. Для команд, которые собирают AI-сервисы, внутренние инструменты и клиентские кабинеты на знакомом стеке, это неприятный сигнал: атакующих интересует уже не просто RCE, а секреты окружения, облачные ключи и точки входа в соседние системы.
По данным The Hacker News, компания VulnCheck наблюдает активную эксплуатацию двух багов. Первый — CVE-2026-0768 в Langflow с оценкой CVSS 9,8: ошибка в проверке пользовательского ввода позволяет выполнить произвольный Python-код с правами root. Второй — CVE-2026-66066, он же KindaRails2Shell, с оценкой 9,5: уязвимость в Ruby on Rails дает неаутентифицированному атакующему читать произвольные файлы на сервере, вытаскивать переменные окружения процесса Rails и секреты вроде secret_key_base, master key, паролей к базе, облачных учетных данных и API-токенов. Дальше цепочка вполне ожидаемая: утечка секретов превращается в удаленное выполнение кода.
Сценарий с Rails особенно показателен тем, что он не выглядит экзотикой. Для эксплуатации CVE-2026-66066 достаточно, чтобы приложение принимало загрузку изображений от недоверенных пользователей и использовало libvips для обработки картинок через Active Storage. Проблема возникает из-за расхождения в том, как Active Storage и libvips читают входные файлы. Иными словами, стандартный для многих веб-команд паттерн «даем пользователю загрузить картинку и делаем variant» внезапно превращается в путь к чтению файлов сервера. VulnCheck отдельно отмечает неприятную деталь: на протестированном сервере Rails 8.1.3.1 патч перекрывал чтение файлов через libvips, но не нейтрализовал десериализацию variation-key через Marshal, так что RCE-гаджет при валидной подписи все еще срабатывал.
С Langflow картина не менее нервная, просто ближе к AI-инфраструктуре. По словам вице-президента VulnCheck по threat research Кейтлин Кондон, злоумышленники запрашивают переменные окружения вроде LANGFLOW_SUPERUSER, OPENAI_API*, AWS_ACCESS* и AWS_SECRET*, читают файл /root/.cache/langflow/secret_key, а заодно проверяют доступ к .ssh и размер .bash_history. Это уже не похоже на слепой шум сканеров. Скорее на быструю инвентаризацию того, что можно унести с узла: ключи к LLM-провайдерам, облачные креды, локальные секреты, следы ручной админской работы. Для компаний, у которых Langflow живет не в песочнице, а рядом с продовскими сервисами, риск тут шире, чем компрометация одной AI-панели.
Отдельный сюжет — география и темп. Источник трафика, по наблюдениям VulnCheck, в основном находится в России, при этом первые обращения попадали исключительно по canary-системам в Великобритании. Позже компания зафиксировала активную эксплуатацию CVE-2026-66066 и по своим приманкам в Сингапуре, Израиле и Великобритании. Исследователь Патрик Гаррити также написал в LinkedIn, что наблюдал активность с одного IP-адреса во Франции, после чего устанавливалось соединение command-and-control с хостом в Израиле. Это еще не повод строить красивую карту APT на стену переговорки, но уже вполне достаточно, чтобы считать кампанию реальной, а не лабораторной.
Контекст тоже важен. VulnCheck пишет, что с 2025 года злоумышленники уже эксплуатировали как минимум 12 уязвимостей, а число успешных попыток по CVE-2026-0769, CVE-2025-3248 и CVE-2026-5027 превысило 15 тысяч. По уязвимым хостам Langflow больше всего систем находится в США, Германии, Малайзии, Бразилии и Индии. В одном из кейсов наблюдения атакующие использовали CVE-2026-5027, чтобы уронить на машину Python-сборщик учетных данных, прокси-агенты и SimpleHelp для удаленного доступа. В другом случае CVE-2025-3248 пошла на подключение узла к ботнету с XMR-майнером; затем злоумышленники отключили auditd, создали форензик-слепую зону и через CVE-2026-0769 доставили .sysd. Проще говоря, AI- и web-платформы все чаще рассматривают не как конечную цель, а как удобный перевалочный пункт для кражи секретов, майнинга и бокового перемещения.
Для разработчиков и ИТ-руководителей вывод довольно приземленный. Если у вас есть Langflow, его нужно рассматривать не как «вспомогательный тул для экспериментов», а как систему с доступом к ключам от облака и LLM-сервисов. Если у вас Rails-приложение принимает картинки от внешних пользователей и обрабатывает их через libvips, зона риска уже не теоретическая. Особенно неприятно, что проблема бьет по привычным инженерным решениям, которые годами считались безопасной рутиной. На начало августа VulnCheck насчитал более 7100 доступных извне уязвимых экземпляров Ruby on Rails, так что пространство для автоматизированной охоты у атакующих вполне рабочее.
Главный вопрос теперь не в том, будут ли такие атаки множиться, а в том, насколько быстро индустрия перестанет считать AI-инструменты и служебные веб-сервисы второстепенной инфраструктурой. Пока секреты к облаку, API и внутренним системам складывают рядом с удобными интерфейсами для разработки, уязвимости Langflow и подобных платформ будут продаваться злоумышленникам не как баги в модных продуктах, а как короткий маршрут к чужому продакшену.