Восстание машин началось с серверов Marimo. ИИ впервые провел автономную кибератаку, рассуждая прямо в терминале
NewsMakerОт эксплойта CVE-2026-39987 до слива PostgreSQL за час.
Злоумышленник использовал ИИ-агента на базе большой языковой модели после взлома публично доступного сервера Marimo. По данным Sysdig , атака началась с эксплуатации CVE-2026-39987 , а затем перешла в быструю цепочку действий: сбор облачных учётных данных, обращение к AWS Secrets Manager, получение закрытого SSH-ключа и подключение к промежуточному серверу, через который был доступ к внутренней базе данных.
Marimo - среда для интерактивных вычислительных блокнотов. Уязвимость CVE-2026-39987 позволяет выполнить системные команды до аутентификации. Ошибка затрагивает все версии Marimo до 0.20.4 включительно, а исправление вышло в версии 0.23.0. После публикации патча уязвимость начали использовать в реальных атаках: исследователи уже видели ручную разведку на приманках и попытки собрать чувствительные данные.
Инцидент, который описала Sysdig, произошёл 10 мая 2026 года. После доступа к открытому экземпляру Marimo злоумышленник извлёк из окружения два облачных учётных секрета. Затем он использовал полученный AWS-ключ для запросов к AWS Secrets Manager и достал оттуда закрытый SSH-ключ.
Через несколько минут этот ключ уже применили для входа на SSH-бастион. Так обычно называют промежуточный сервер, через который администраторы или сервисы подключаются к закрытым внутренним системам. Затем атакующий открыл восемь коротких SSH-сессий к следующему серверу и выгрузил схему вместе с полным содержимым внутренней базы PostgreSQL. Этап с базой занял меньше двух минут, а вся цепочка атаки продлилась чуть больше часа.
Главная необычная часть истории не в самой уязвимости Marimo, а в поведении после взлома. Sysdig считает, что дальнейшие действия выполнял ИИ-агент, а не обычный заранее написанный скрипт. Исследователи выделили четыре признака, которые указывают на автоматизированную работу с элементами планирования и адаптации.
Первый признак - способ работы с базой данных. У атакующего не было заранее подготовленной схемы, понятного имени приложения на диске или готового плана для конкретной среды. Несмотря на это, цепочка быстро привела к таблице с учётными данными. Агент не знал устройство системы заранее, но по ходу атаки анализировал найденные подсказки и выбирал следующий шаг.
Второй признак связан с фрагментом планирования, который случайно попал в поток команд. Sysdig обнаружила китайскую фразу со смыслом «посмотрим, что ещё можно сделать». Она появилась во время поиска учётных данных и выглядела не как часть обычного набора команд, а как след рассуждения или промежуточной инструкции, которую агент не должен был вывести наружу.
Третий признак - формат команд. Они были устроены так, чтобы результат удобно обрабатывала машина: отдельные блоки разделялись специальным маркером, вывод ограничивался по объёму, постраничный просмотр отключался, а поток ошибок отбрасывался, чтобы не добавлять лишний шум. Такой стиль больше похож на диалог между инструментами, чем на привычную работу человека в терминале.
Четвёртый признак - передача найденных значений из одного шага в другой. Например, агент сначала проверял наличие нужного файла с SSH-ключом, а затем выводил его содержимое. В другом месте он использовал данные из файла с параметрами подключения к PostgreSQL и подставлял их в дальнейшие действия. По оценке Sysdig, такая связка указывает на систему, которая читает собственный предыдущий вывод и строит следующий запрос на его основе.
Для защитников этот сценарий неприятен тем, что ИИ-агент не обязан заранее иметь готовую инструкцию под конкретную сеть. Обычный скрипт часто ломается, если не находит ожидаемый файл, схему базы или рабочий пароль. Агент может заметить расхождение, подобрать другой путь и продолжить атаку. В таком режиме ограничением становится не написание отдельного набора команд под каждую цель, а стоимость и время работы модели.
Sysdig описывает эту атаку как пример новой практической проблемы. Если злоумышленник получает начальный доступ, ИИ-агент может быстро разобраться в незнакомой среде, найти полезные секреты, перейти к следующей системе и собрать данные без длительной ручной работы. В данном случае путь прошёл от уязвимого Marimo до внутренней PostgreSQL через облачные ключи, AWS Secrets Manager и SSH-бастион.
Администраторам рекомендуют обновить Marimo до актуальной версии, проверить, нет ли публично доступных экземпляров сервиса, и пересмотреть все окружения, где могли храниться секреты. Также стоит заменить облачные учётные данные, API-ключи и SSH-ключи, если есть риск, что они оказались на скомпрометированном хосте. В подобных инцидентах важно считать утечкой не только сам сервер с уязвимостью, но и все ключи, которые атакующий мог достать после первого входа.
Злоумышленник использовал ИИ-агента на базе большой языковой модели после взлома публично доступного сервера Marimo. По данным Sysdig , атака началась с эксплуатации CVE-2026-39987 , а затем перешла в быструю цепочку действий: сбор облачных учётных данных, обращение к AWS Secrets Manager, получение закрытого SSH-ключа и подключение к промежуточному серверу, через который был доступ к внутренней базе данных.
Marimo - среда для интерактивных вычислительных блокнотов. Уязвимость CVE-2026-39987 позволяет выполнить системные команды до аутентификации. Ошибка затрагивает все версии Marimo до 0.20.4 включительно, а исправление вышло в версии 0.23.0. После публикации патча уязвимость начали использовать в реальных атаках: исследователи уже видели ручную разведку на приманках и попытки собрать чувствительные данные.
Инцидент, который описала Sysdig, произошёл 10 мая 2026 года. После доступа к открытому экземпляру Marimo злоумышленник извлёк из окружения два облачных учётных секрета. Затем он использовал полученный AWS-ключ для запросов к AWS Secrets Manager и достал оттуда закрытый SSH-ключ.
Через несколько минут этот ключ уже применили для входа на SSH-бастион. Так обычно называют промежуточный сервер, через который администраторы или сервисы подключаются к закрытым внутренним системам. Затем атакующий открыл восемь коротких SSH-сессий к следующему серверу и выгрузил схему вместе с полным содержимым внутренней базы PostgreSQL. Этап с базой занял меньше двух минут, а вся цепочка атаки продлилась чуть больше часа.
Главная необычная часть истории не в самой уязвимости Marimo, а в поведении после взлома. Sysdig считает, что дальнейшие действия выполнял ИИ-агент, а не обычный заранее написанный скрипт. Исследователи выделили четыре признака, которые указывают на автоматизированную работу с элементами планирования и адаптации.
Первый признак - способ работы с базой данных. У атакующего не было заранее подготовленной схемы, понятного имени приложения на диске или готового плана для конкретной среды. Несмотря на это, цепочка быстро привела к таблице с учётными данными. Агент не знал устройство системы заранее, но по ходу атаки анализировал найденные подсказки и выбирал следующий шаг.
Второй признак связан с фрагментом планирования, который случайно попал в поток команд. Sysdig обнаружила китайскую фразу со смыслом «посмотрим, что ещё можно сделать». Она появилась во время поиска учётных данных и выглядела не как часть обычного набора команд, а как след рассуждения или промежуточной инструкции, которую агент не должен был вывести наружу.
Третий признак - формат команд. Они были устроены так, чтобы результат удобно обрабатывала машина: отдельные блоки разделялись специальным маркером, вывод ограничивался по объёму, постраничный просмотр отключался, а поток ошибок отбрасывался, чтобы не добавлять лишний шум. Такой стиль больше похож на диалог между инструментами, чем на привычную работу человека в терминале.
Четвёртый признак - передача найденных значений из одного шага в другой. Например, агент сначала проверял наличие нужного файла с SSH-ключом, а затем выводил его содержимое. В другом месте он использовал данные из файла с параметрами подключения к PostgreSQL и подставлял их в дальнейшие действия. По оценке Sysdig, такая связка указывает на систему, которая читает собственный предыдущий вывод и строит следующий запрос на его основе.
Для защитников этот сценарий неприятен тем, что ИИ-агент не обязан заранее иметь готовую инструкцию под конкретную сеть. Обычный скрипт часто ломается, если не находит ожидаемый файл, схему базы или рабочий пароль. Агент может заметить расхождение, подобрать другой путь и продолжить атаку. В таком режиме ограничением становится не написание отдельного набора команд под каждую цель, а стоимость и время работы модели.
Sysdig описывает эту атаку как пример новой практической проблемы. Если злоумышленник получает начальный доступ, ИИ-агент может быстро разобраться в незнакомой среде, найти полезные секреты, перейти к следующей системе и собрать данные без длительной ручной работы. В данном случае путь прошёл от уязвимого Marimo до внутренней PostgreSQL через облачные ключи, AWS Secrets Manager и SSH-бастион.
Администраторам рекомендуют обновить Marimo до актуальной версии, проверить, нет ли публично доступных экземпляров сервиса, и пересмотреть все окружения, где могли храниться секреты. Также стоит заменить облачные учётные данные, API-ключи и SSH-ключи, если есть риск, что они оказались на скомпрометированном хосте. В подобных инцидентах важно считать утечкой не только сам сервер с уязвимостью, но и все ключи, которые атакующий мог достать после первого входа.