В notebook-платформе Marimo закрыли уязвимость Marimo с оценкой CVSS 8,7: специально подготовленный файл мог запустить навязанную атакующим MCP-команду локально еще до выполнения ячеек. Для разработчиков, которые привыкли открывать чужие ноутбуки «просто посмотреть», это неприятное напоминание: в эпоху AI-инструментов опасной поверхностью становится уже не только код, но и метаданные вокруг него.
Об инциденте сообщает The Hacker News со ссылкой на запись VulnCheck в статусе CVE Numbering Authority. Уязвимость получила идентификатор CVE-2026-75149 и затрагивала версии Marimo ниже 0.23.15. Сценарий атаки выглядел довольно приземленно и потому особенно неприятно: злоумышленник подсовывает жертве notebook со специально оформленной конфигурацией, жертва открывает его в режиме редактирования, а указанный в конфиге MCP-командный процесс запускается как локальный subprocess еще до того, как пользователь вообще успеет исполнить хоть одну ячейку. Аутентификация атакующему не требовалась, но было нужно действие со стороны пользователя: открыть файл.
По сути, речь идет о code injection через конфигурацию notebook. В импортированной в OSV записи сказано, что вредоносный notebook мог передать управляемую атакующим команду MCP-сервера через свои настройки. Дальше срабатывал не код из ячеек, а инфраструктурная обвязка вокруг notebook, и это, пожалуй, главное в этой истории. У многих команд есть негласная привычка считать ноутбук безопасным, пока не нажата кнопка Run. Здесь эта интуиция не работала: триггером становилось само открытие файла в edit mode. Для внутренних платформ, data science-команд, AI-прототипирования и быстрых демо это плохая новость, потому что именно такие артефакты чаще всего путешествуют между людьми без строгого контроля происхождения.
Исправление вошло в Marimo 0.23.15, релиз которого был опубликован 23 июля 2026 года. Сам CVE опубликовали 19 августа, а на 25 августа 2026 года, как отмечает The Hacker News, актуальной версией пакета на PyPI уже была 0.24.0, выпущенная 17 августа. Разработчики Marimo в рамках hardening-патча для PEP 723 начали трактовать метаданные notebook как потенциально враждебные и пропускать notebook-supplied-конфигурацию через allowlist. Из пользовательских секций были удалены ai, mcp, completion, secrets и server. Отдельный regression-тест для MCP, по данным публикации, проверяет именно это поведение: вредоносная секция должна быть вырезана, даже если notebook пытается подменить URL или команду.
История была бы просто очередным патчем, если бы не контекст. Это уже не первая проблема Marimo за короткий срок и не первый случай, когда атакующая сторона использует доверие к конфигурации. В материале упоминается отдельная уязвимость CVE-2026-67618 с CVSS 7,1, раскрытая 4 августа 2026 года. Она тоже затрагивала версии до 0.23.15 и была связана с тем, что через метаданные notebook можно было подставить атакующий AI base_url. Дальше сценарий выглядел так: оператор открывает вредоносный notebook, позже отправляет AI-запрос, и указанный endpoint получает его API-ключ, хотя ни одна ячейка при этом не обязана исполняться. Еще раньше у Marimo была CVE-2026-39987: в версиях 0.20.4 и ниже отсутствовала корректная проверка аутентификации на endpoint /terminal/ws, что могло привести к получению полного PTY-shell и запуску произвольных команд. Для той проблемы Marimo указывала исправленной версию 0.23.0.
Для рынка AI-devtools это плохой, но полезный сигнал. Чем активнее notebook-продукты, агентные надстройки и MCP-интеграции превращаются из игрушек для локальных экспериментов в рабочую часть пайплайна, тем меньше права на «доверие по умолчанию» остается у файлового формата и встроенных настроек. В классическом AppSec уже давно привыкли смотреть не только на исполняемый код, но и на десериализацию, конфиги, плагины, хуки и supply chain. Теперь тот же урок ускоренно доходит до AI-экосистемы. Разработчикам и платформенным командам это добавляет вполне земных задач: обновлять Marimo без задержек, не открывать notebook из сомнительных источников в edit mode на рабочих машинах, изолировать окружения для анализа внешних артефактов и отдельно проверять, какие настройки notebook вообще имеет право приносить с собой.
Для бизнеса значение тоже очевидно. Notebook-файл давно перестал быть безобидным приложением к исследованию или демо-модели. Если через него можно дернуть локальный subprocess или незаметно увести ключи на внешний endpoint, проблема уже выходит за рамки удобства конкретного инструмента и становится вопросом корпоративной гигиены доступа. В ближайшие месяцы рынок AI-инструментов, похоже, будет все жестче проводить границу между «контентом notebook» и «настройками среды». И чем раньше эту границу начнут считать обязательной, а не факультативной, тем меньше сюрпризов будет у команд, которые пока открывают чужие ноутбуки с тем же спокойствием, с каким раньше открывали PDF.