Критическую уязвимость в Marimo начали использовать меньше чем через 10 часов после публикации

Критическую уязвимость в Marimo, открытой реактивной notebook-платформе для Python, начали использовать в атаках меньше чем через 10 часов после публичного раскрытия. По данным Sysdig, первый реальный эпизод эксплуатации зафиксировали через 9 часов 41 минуту после публикации advisory на GitHub.

Проблема отслеживается как CVE-2026-39987 и GHSA-2679-6mx9-h9xc. Речь идёт о pre-auth RCE, то есть об удалённом выполнении кода без входа в систему. Уязвимость находится в WebSocket-обработчике /terminal/ws: этот эндпойнт принимал соединение, не проверяя аутентификацию, и позволял атакующему получить полноценную интерактивную PTY-оболочку и выполнять системные команды. GitHub advisory указывает, что затронуты версии Marimo до 0.20.4 включительно, а исправление вошло в 0.23.0.

Ошибка выглядит пугающе просто. В advisory сказано, что другие WebSocket-эндпойнты, например /ws, вызывают validate_auth() и проверяют доступ. А вот /terminal/ws ограничивался проверкой режима работы и поддержки платформы, после чего сразу принимал соединение. В результате одному WebSocket-подключению было достаточно, чтобы открыть полноценную shell-сессию на сервере. В GitHub advisory отдельно отмечено, что в типовом Docker-развёртывании команды могли выполняться с правами root.

На момент первой эксплуатации не было опубликованного PoC-кода, однако злоумышленник собрал рабочий эксплойт прямо по описанию из advisory. Исследователи наблюдали, как атакующий подключился к уязвимому эндпойнту, быстро проверил выполнение команд, вернулся для ручной разведки, а затем вытащил файлы с учётными данными. Весь сценарий кражи секретов, по данным Sysdig, уложился менее чем в три минуты.

По таймлайну Sysdig advisory был опубликован 8 апреля 2026 года в 21:50 UTC, первая эксплуатация произошла 9 апреля в 07:31 UTC, а уже в 07:44 UTC злоумышленник выгрузил .env-файл с секретами. Исследователи также зафиксировали ещё одну сессию позже утром. Это значит, что окно на реакцию у администраторов было буквально в несколько часов ночью или ранним утром.

Содержимое атаки тоже выглядит типично для современных кампаний. Злоумышленник сначала проверил возможность выполнить команды, затем осмотрел файловую систему, попытался найти SSH-ключи и служебные файлы, а после этого прочитал .env, где оказались переменные окружения с облачными и приложенческими секретами. SecurityWeek пишет, что основной целью была именно кража учётных данных. Для notebook-платформ это особенно опасно: на таких узлах часто лежат ключи к базам данных, API-токены, облачные доступы и внутренние сервисные учётные данные.

Sysdig уточняет, что в первые 12 часов после публикации advisory активную эксплуатацию они увидели только с одного IP-адреса, но при этом ещё 125 уникальных адресов занимались разведкой: сканировали порты и прощупывали HTTP-интерфейс. После раскрытия такие баги почти сразу попадают в поле зрения широкого круга атакующих, даже если до полноценного взлома доходит не каждый.