Атакующий за восемь секунд прошёл от Marimo RCE до SSH-бастиона
Sysdig выявила атаку, в которой оператор использовал критическую уязвимость CVE-2026-39987 в Marimo с оценкой CVSS 9,3 и за восемь секунд перешёл от уязвимого ноутбука к SSH-бастиону. Проблема позволяет выполнять код до аутентификации и затрагивает все версии Marimo; активная эксплуатация началась в течение нескольких часов после раскрытия.
Цепочка доступа через облачные секреты
После первоначального доступа злоумышленник получил полную интерактивную оболочку на скомпрометированном экземпляре. Затем он использовал найденные там учётные данные AWS, обратился к AWS Secrets Manager, получил закрытый SSH-ключ и применил его для аутентификации на bastion host.
По временной шкале Sysdig, новое WebSocket-соединение было установлено в 18:57:22. В 18:57:26 зафиксирован запрос к сохранённым приложением учётным данным, который вернул ключ AWS, а в 18:57:30 наблюдалась SSH-аутентификация на бастионе. Таким образом, переход от доступа к приложению до входа на промежуточный сервер занял восемь секунд.
Ручной инструментарий вместо агентной автоматизации
Исследователи отмечают, что оператор не применял распознаваемые общедоступные offensive-инструменты и не задействовал ИИ-агента. За девятичасовую сессию он выполнил более 850 интерактивных команд и создавал и отлаживал скрипты непосредственно во время атаки.
Ключевым элементом стал один запущенный в фоне процесс Python3. Он получал учётные данные, запрашивал SSH-ключ из Secrets Manager, записывал его на диск и подключался к бастиону по SSH. Также атакующий настроил listener, похожий на asyncssh, на принадлежащем ему VPS.
Что проверить после публикации критической RCE
Наблюдение показывает, что скорость развития атаки определяется не только ИИ-инструментами: квалифицированный оператор способен быстро собрать собственную цепочку и обойти предсказуемые ловушки. Для Marimo особенно важны оперативная установка исправлений, проверка открытых WebSocket-эндпоинтов и поиск признаков несанкционированного выполнения команд.
Бизнесу следует отдельно контролировать, какие роли и ключи доступны приложению, ограничивать права на чтение секретов в AWS Secrets Manager и сопоставлять такие обращения с последующими SSH-подключениями. Такая связка событий позволяет быстрее заметить переход от компрометации приложения к доступу во внутреннюю инфраструктуру.