Атака на Marimo показала неприятную вещь: скорость, которую защитники уже привыкли списывать на ИИ, вполне доступна живому оператору с хорошими руками. По данным The Hacker News, исследователи Sysdig описали инцидент, где злоумышленник после эксплуатации RCE в Marimo добрался до SSH-бастиона за восемь секунд.
Речь идет о CVE-2026-39987, уязвимости удаленного выполнения кода до аутентификации с оценкой CVSS 9.3. Она затрагивает все версии Marimo и, по данным Sysdig, начала активно эксплуатироваться уже через несколько часов после публичного раскрытия. Для команд, которые держат ноутбуки, песочницы и внутренние инструменты в облаке, это не академическая история про «еще один CVE», а сценарий из рабочего вторника.
Marimo в этом кейсе стал первой дверью. Атакующий подключился к открытому WebSocket-эндпоинту /terminal/ws, получил интерактивную оболочку, вытащил AWS-учетные данные из скомпрометированного инстанса, обратился к AWS Secrets Manager, забрал приватный SSH-ключ и использовал его для входа на bastion host. В одном из фрагментов таймлайна Sysdig зафиксировала: в 18:57:22 появилось новое WebSocket-соединение, в 18:57:26 был выполнен поиск сохраненных учетных данных приложения, а в 18:57:30 уже прошла SSH-аутентификация на бастионе.
Главная деталь здесь не только в скорости. Исследователи отдельно подчеркивают, что оператор не использовал узнаваемый публичный offensive tooling и не опирался на агентный ИИ. За девятичасовую сессию он выполнил более 850 интерактивных команд, писал и отлаживал скрипты прямо по ходу атаки, а итоговая цепочка свелась к одному фоновому запуску Python 3. Этот скрипт забирал credential, доставал SSH-ключ из Secrets Manager, записывал его на диск и сразу подключался к бастиону.
Для SOC и cloud security-команд это неприятный контраргумент к популярной успокаивающей версии: мол, «машинная» скорость атаки означает, что где-то крутится агент, а значит, его можно поймать по характерным ошибкам и шаблонам. Sysdig пишет, что этот оператор прошел мимо ловушки, в которую попадали агентные атакующие при работе с тем же CVE. Иными словами, атака на Marimo оказалась быстрой, но не шумной в том смысле, в каком защитники могли ожидать.
На практике это бьет сразу по нескольким зонам ответственности. Разработчикам и DevOps стоит еще раз посмотреть, какие notebook-среды, внутренние терминалы, демо-инстансы и исследовательские сервисы торчат наружу без строгой аутентификации. Командам безопасности — проверить, насколько быстро они видят связку «веб-эксплуатация → облачные секреты → SSH». Бизнесу — перестать считать бастион магической стеной, если ключи к нему лежат в том же контуре, куда можно попасть через RCE.
Отдельный слой проблемы — секреты. AWS Secrets Manager сам по себе не виноват: сервис делает то, что ему разрешили делать выданные учетные данные. Но если приложение после компрометации получает доступ к ключам, которые открывают путь дальше по инфраструктуре, инцидент мгновенно перестает быть локальным. В этом смысле атака на Marimo снова напоминает старую, скучную и болезненную истину: права сервисных аккаунтов почти всегда интереснее самой уязвимости.
На фоне этой истории Hunt.io описала еще одну кампанию — уже против Redis. Исследователи нашли 3562 скомпрометированных Redis-сервера после, вероятно, широкого сканирования интернета по порту 6379. Атакующие параллельно запускали несколько направлений: поиск WordPress-целей, попытки SSH-инъекции через append-only file в Redis и проверки Lua sandbox escape. Масштабно сработал метод rogue replication через команду SLAVEOF, после чего на серверы ставился XMRig-майнер.
Любопытно, что пострадали Redis-инстансы от версии 2.8.17, выпущенной в 2015 году, до 7.2.0 от 2023 года. Hunt.io делает вывод: проблема не в конкретном баге одной версии, а в отсутствии нормальной аутентификации и экспонировании сервиса туда, где ему быть не надо. Попытки SSH key injection и MongoDB sandbox escape, по их данным, не дали результата в 2810 проверках, а цепочка WordPress от credential до web shell была восстановлена, но не подтверждена как массово успешная.
Эти эпизоды складываются в один тренд: злоумышленникам уже не обязательно выбирать между массовой автоматизацией и ручным мастерством. ИИ снижает стоимость разведки и рутинной эксплуатации, но опытный оператор все еще может двигаться быстрее правил реагирования, особенно если инфраструктура сама услужливо подсовывает ему WebSocket-терминал, облачные ключи и SSH-доступ. Следующий практичный вопрос для IT-команд не «использовал ли атакующий ИИ», а «успеем ли мы заметить переход от первого шелла к критичному доступу раньше, чем он займет восемь секунд».