После эксплуатации критической уязвимости в Marimo злоумышленники за час с небольшим прошли путь от первичного доступа до кражи содержимого внутренней PostgreSQL-базы. Самый неприятный штрих в этой истории не сам CVE-2026-39987, а то, что постэксплуатацию, по данным исследователей, вел LLM-агент: не скрипт с жесткой логикой, а система, которая подстраивается под среду на лету. Для российских команд, которые держат публично доступные ноутбуки, облачные секреты и bastion-хосты в одной цепочке доверия, это уже не футуризм, а вполне приземленный сценарий инцидента.
Как пишет The Hacker News, инцидент зафиксировала Sysdig 10 мая 2026 года. Атакующий получил доступ к доступному из интернета Marimo-ноутбуку через CVE-2026-39987, затем извлек с хоста две облачные учетные записи, использовал одну из них для запросов в AWS Secrets Manager и достал оттуда приватный SSH-ключ. После этого последовали восемь коротких параллельных SSH-сессий на downstream bastion-сервер, а уже на этой стадии была выгружена схема и полное содержимое внутренней PostgreSQL-базы. На саму фазу exfiltration базы, по оценке Sysdig, ушло меньше двух минут.
Сама уязвимость выглядит достаточно неприятно даже без всякого ИИ. CVE-2026-39987 описывается как критическая pre-authenticated RCE в Marimo, затрагивающая все версии до 0.20.4 включительно. То есть атакующему не требовалась аутентификация, чтобы выполнить произвольные системные команды. Исправление вышло в версии 0.23.0 в прошлом месяце, но окно между публикацией патча и массовым интересом со стороны атакующих, как обычно, оказалось коротким. The Hacker News отмечает, что дефект уже использовали в реальных атаках: сначала для ручной разведки на honeypot-системах и попыток собрать чувствительные данные, а теперь и для более собранной, целевой постэксплуатации.
Почему Sysdig вообще решила, что за действиями стоял именно LLM-агент, а не просто аккуратный оператор? Исследователи привели четыре косвенных признака. Во-первых, атакующий смог импровизировать с дампом базы, не имея заранее ни схемы, ни очевидных подсказок о приложении на диске. Во-вторых, в потоке команд всплыл комментарий на китайском: «посмотрим, что еще можно сделать». Такие утечки обычно плохо сочетаются с заранее подготовленным playbook и гораздо лучше сочетаются с агентом, который строит план по ходу работы. В-третьих, команды были оформлены так, будто их основной потребитель не человек, а машина: разделители ---, ограничение объема вывода, отключение less, отбрасывание stderr ради снижения шума. В-четвертых, цепочка действий демонстрировала передачу значений из предыдущего вывода в следующий шаг. Классический пример: сначала проверить наличие файла вроде ~/.ssh/id_ed25519, затем читать его содержимое; сначала вытащить пароль из ~/.pgpass, потом использовать его в следующей команде. Это уже очень похоже на контур «инструмент -> вывод -> следующая гипотеза», а не на тупой bash-скрипт.
Здесь важен не только сам факт использования ИИ, а изменение экономики атаки. Обычному оператору нужно либо заранее знать целевую среду, либо тратить время на подготовку playbook под класс систем. LLM-агенту достаточно общих представлений о том, как обычно устроены ноутбуки, облачные учетные данные, bastion-хосты и базы данных. Если один путь не сработал, он не обязательно останавливается: он читает ошибку, выбирает следующий вариант и продолжает. Именно это и делает историю неприятной для защитников. Проблема больше не сводится к тому, есть ли у злоумышленника готовый набор скриптов под ваш стек. Вопрос в том, насколько быстро он может интерпретировать среду и собирать атаку в реальном времени.
Для разработчиков и DevOps-команд у этого кейса есть довольно прозаичный вывод: публичный notebook-сервис больше нельзя рассматривать как что-то второстепенное по сравнению с «настоящим продом». Если уязвимый Marimo имеет сетевую доступность, видит переменные окружения, IAM-ключи или может дернуть Secrets Manager, он уже находится в боевой цепочке. А если за ним стоит bastion и внутренняя база, то компрометация одного удобного инструмента для аналитики превращается в маршрут к данным компании. Особенно неприятно, что в описанном сценарии не понадобились экзотические техники: все сложилось из типовых компонентов современной инфраструктуры, которые сами по себе считаются нормальной практикой.
Для бизнеса это означает еще одну вещь: реагировать на такие истории как на «локальную дыру в нишевом инструменте» уже поздно. Marimo здесь важен как входная точка, но ценность кейса в другом. Атака показала, что LLM-агент способен быстро собрать разрозненные секреты, понять, куда они ведут, и использовать их без длинной ручной паузы между этапами. Для служб ИБ это аргумент в пользу более жесткой сегментации, минимизации прав у облачных ключей, запрета на долгоживущие SSH-ключи в секрет-хранилищах и отдельного аудита всех internet-reachable сервисов, которые разработчики поднимают «временно» и забывают. Базовые меры, которые рекомендуют исследователи, тоже никуда не делись: обновить Marimo до актуальной версии, найти все публично доступные инстансы, проверить журналы на признаки эксплуатации и ротировать скомпрометированные учетные данные, API-ключи и SSH-ключи.
Главный вопрос после этого инцидента звучит не как «заменят ли LLM-агенты человека в атаке», а куда прозаичнее: сколько еще звеньев типовой инженерной инфраструктуры они смогут проходить без заранее написанного сценария. Если раньше защита часто выигрывала на том, что злоумышленник упрется в нестандартную схему, странное имя хоста или отсутствующий файл, то теперь таких мелких поломок может быть уже недостаточно. И это плохая новость для всех, кто по-прежнему хранит секреты так, будто следующую команду в терминале обязательно будет вводить усталый человек, а не терпеливый LLM-агент.