Что изменилось#
Инцидент связан с CVE-2026-39987 — критической уязвимостью удалённого выполнения кода без предварительной аутентификации в Marimo. По данным источника, проблема затрагивает версии Marimo до 0.20.4 включительно и исправлена в версии 0.23.0.
Источник: The Hacker News по исследованию Sysdig — https://thehackernews.com/2026/05/attackers-use-llm-agent-for-post.html
Сама по себе эта часть хорошо знакома командам безопасности: доступный из интернета сервис, раскрытая RCE, активная эксплуатация и срочное обновление. Новое — в том, что происходило после первичного доступа.
Sysdig наблюдала, как неизвестный злоумышленник скомпрометировал публично доступный notebook Marimo, вытащил с хоста две облачные учётные записи, использовал AWS access key для обращения к AWS Secrets Manager, получил SSH private key, а затем применил этот ключ против downstream SSH bastion server. По данным отчёта, активность на bastion привела к выгрузке схемы и полного содержимого внутренней базы PostgreSQL менее чем за две минуты. Вся цепочка заняла больше часа.
Главный вывод отчёта уже, чем может звучать в заголовках. LLM не создала CVE. Она не заменила необходимость в открытой инфраструктуре, действующих учётных данных, доступных секретах и путях для бокового перемещения. Утверждение Sysdig в другом: LLM-агент, похоже, вёл этап post-exploitation после того, как доступ уже был получен.
Это важно, потому что именно после первичного взлома многие инциденты становятся по-настоящему разрушительными. Первичный доступ часто шумный и типовой. Дорогая часть для атакующих — подстроиться под среду жертвы: найти учётные данные, прочитать пути к файлам, понять имена сервисов, обработать отсутствующие файлы и решить, что пробовать дальше. Аргумент Sysdig: агент может снижать эту цену.
Почему эта CVE важна для эксплуатации и защиты#
CVE-2026-39987 была входной точкой в этом случае, но операционный риск шире, чем один экземпляр Marimo.
Уязвимый сервис был доступен из интернета. После компрометации атакующий нашёл облачные учётные данные на хосте. Эти данные позволяли обращаться к AWS Secrets Manager. В Secrets Manager лежал SSH private key. Этот ключ открыл путь к bastion server. Через bastion злоумышленник добрался до внутренней базы PostgreSQL.
Каждый шаг — отдельный вопрос к контролям безопасности. Обновление Marimo закрывает известную входную дверь. Но оно не отвечает на вопросы: были ли облачные учётные данные выданы с избыточными правами, были ли секреты слишком широко доступны, были ли ротированы SSH-ключи, отслеживался ли доступ к bastion, сработало бы оповещение на выгрузку базы.
В этом и состоит реальный риск для приватности и операций. Notebook-сервис, открытый в интернет, стал маршрутом к содержимому базы данных. Если внутренняя PostgreSQL хранила данные клиентов, пользовательские записи, аналитику, секреты приложения или чувствительные бизнес-таблицы, ущерб не ограничивается исходным хостом.
Отчёт также укладывается в модель, к которой защитникам стоит привыкать: атакующим не нужно идеально знать цель. Им нужен достаточный доступ, достаточные права и достаточно времени, чтобы найти следующий полезный зацеп.
Агентский сценарий усиливает эту проблему. Sysdig указывает на несколько признаков LLM-driven активности: вывод команд был подготовлен для машинной обработки, использовались разделители, ограниченные захваты вывода, подавление шумного вывода, передача значений из результатов прошлых команд в следующие шаги, а также комментарий планирования на китайском языке, появившийся в потоке команд. Один пример: перед чтением SSH-ключа через cat сначала проверялось его наличие командой ls. Другой пример: содержимое ~/.pgpass использовалось для последующего доступа к базе.
Это не доказывает конкретную модель, вендора или набор инструментов. Но это поддерживает более узкий вывод: оператор мог использовать агентный workflow, который смотрел на вывод, корректировал действия и продолжал цепочку.
Эксплуатируемость — не весь риск#
Частая ошибка после отчёта о CVE — свести всё к бинарному вопросу патча: уязвимо или нет, эксплуатировалось или нет. Этот случай показывает, почему такого подхода мало.
Эксплуатируемость CVE-2026-39987 важна, потому что она может дать выполнение команд без аутентификации. Но радиус поражения зависит от того, что скомпрометированный сервис видит и до чего может дотянуться. Исправленный сервис при утёкших долгоживущих ключах в другом месте всё ещё может быть риском через другие маршруты. Неисправленный сервис с жёстким egress, без локальных секретов, с ограниченными правами identity и сильным логированием всё равно уязвим, но атакующему сложнее превратить выполнение кода в кражу данных.
The Hacker News пишет, что более ранняя эксплуатация включала ручную разведку honeypot-систем и попытки собрать чувствительные данные. Наблюдение Sysdig идёт по похожему пути, но с вероятным использованием агента после входа. Это смещает задачу защитников: нужно ловить не один жёсткий скрипт, а адаптивные последовательности.
Жёстко заданный скрипт часто ломается, если файла нет или схема отличается. Агент может прочитать ошибку и выбрать другой путь. Это не магия. Это делает слабые предположения опаснее.
Практический вопрос для security operations прост: если атакующий приземлится на один открытый application server, сколько полезных секретов он успеет достать до того, как человек заметит?
Что проверить сейчас#
Начните с экспозиции Marimo. Найдите все экземпляры Marimo, доступные из интернета, и проверьте, обновлены ли они за пределы затронутого диапазона, описанного в источнике. Если уязвимый экземпляр был открыт наружу, рассматривайте это как возможный путь компрометации, а не просто тикет на обновление.
Затем проверьте связанную цепочку доверия.
🧭 Практические проверки:
- Убедитесь, что Marimo обновлён до исправленной версии, в первую очередь на публичных экземплярах.
- Проверьте логи на выполнение команд, поиск учётных данных, необычное чтение файлов и исходящую активность с хостов Marimo.
- Найдите облачные учётные данные, хранящиеся на хосте, в environment variables, notebook-файлах, shell history, конфигурациях или директориях приложения.
- Проверьте AWS API calls от учётных данных, связанных с затронутыми системами, особенно обращения к Secrets Manager.
- Ротируйте раскрытые или потенциально раскрытые учётные данные, API keys и SSH keys.
- Пересмотрите права Secrets Manager. Скомпрометированный application host не должен автоматически иметь широкий read-доступ к ценным SSH-ключам.
- Проверьте SSH-логи bastion на короткие, параллельные или необычные сессии после подозрительной cloud API активности.
- Изучите логи доступа PostgreSQL на перечисление схем, массовые чтения, дампы или доступ через bastion-маршруты, не похожие на нормальную работу.
- Добавьте детектирование потоков команд, подготовленных для автоматизации: повторяющиеся разделители, ограниченный захват вывода, подавление stderr и быстрое повторное использование значений между командами.
Эти проверки полезны даже тем, кто не использует Marimo. Шаблон переносим: компрометация публичного приложения, кража локальных учётных данных, получение cloud-секрета, SSH-переход, дамп базы. Такая цепочка может возникнуть вокруг многих developer tools и внутренних платформ.
Для команд, которые занимаются open source security и software supply chain controls, это ещё один сигнал: обновление нужно связывать с операционными проверками. CVE advisory показывает, где находится известная слабость. Он не говорит, использовал ли её атакующий, какие ключи были раскрыты и какие downstream-системы доверяли этим ключам.
Связанный материал GigaTap: OpenSSF’s April signal: make security artifacts operational — https://gigatap.top/en/articles/openssfs-april-signal-make-security-artifacts-operational
Чего не стоит утверждать#
Не превращайте этот случай в тезис «AI-атакующие могут взломать что угодно». Источник этого не подтверждает.
Наблюдаемая цепочка всё равно зависела от конкретных провалов или экспозиций: публично доступный уязвимый notebook Marimo, учётные данные в скомпрометированной среде, доступ к AWS Secrets Manager, SSH private key, который подошёл к bastion, и доступ к базе через этот путь. Уберите или ограничьте любое из этих звеньев — атака станет сложнее.
Также не стоит считать каждую странную последовательность команд доказательством использования LLM. Индикаторы Sysdig значимы потому, что появились вместе: адаптивный поток команд, машинно-ориентированное форматирование, передача результатов между шагами и утёкший комментарий планирования. Один разделитель или одна необычная shell-команда сами по себе недостаточны.
Более сильный вывод приземлённее. Agent-assisted post-exploitation может ускорить атакующих при навигации по незнакомым системам. Это меняет ожидания защитников. Контроли, которые полагаются на то, что атакующие будут медленными, растерянными или застрянут на мелких различиях среды, будут быстро устаревать.
Патч для CVE — первый шаг. Следующая важная работа — доказать, что раскрытые учётные данные не превратились в доступ к downstream-системам.