Критична уразливість CVE-2026-39987 в популярному open-source блокноті для аналізу даних Marimo наочно показала, наскільки швидко сьогодні атакувальники реагують на публічні повідомлення про проблеми безпеки. За даними Sysdig, перша спроба експлуатації була зафіксована менш ніж через 10 годин після оприлюднення опису уразливості, ще до появи публічного proof-of-concept експлойта.
Уразливість CVE-2026-39987 в Marimo: критичний RCE через WebSocket
Уразливість CVE-2026-39987 отримала оцінку 9,3 за шкалою CVSS і зачіпає всі версії Marimo до та включно 0.20.4. Проблему виправлено в релізі 0.23.0, тому оновлення до цієї або новішої версії є критично важливим для будь-якого інстанса, доступного з мережі.
Відсутня автентифікація на WebSocket-ендпоінті /terminal/ws
Корінь проблеми полягає в тому, що WebSocket-ендпоінт /terminal/ws у вразливих версіях Marimo не виконує перевірку автентифікації. Інші WebSocket-маршрути (наприклад, /ws) коректно викликають функцію validate_auth(), тоді як /terminal/ws обмежується лише перевіркою режиму роботи та підтримуваної платформи, повністю пропускаючи етап валідації користувача.
У результаті будь-який неавтентифікований віддалений користувач може встановити WebSocket-з’єднання з термінальним ендпоінтом і отримати повноцінну PTY-оболонку на сервері. Фактично кожен інтернет-доступний інстанс Marimo з уразливою версією надає атакувальнику інтерактивний віддалений доступ до системи без жодних облікових даних – це класичний сценарій remote code execution (RCE).
Honeypot Sysdig: перша експлуатація через 9 годин 41 хвилину
Для спостереження за реальною активністю зловмисників Sysdig розгорнула уразливий інстанс Marimo як honeypot. Перше зафіксоване підключення до /terminal/ws відбулося вже через 9 годин 41 хвилину після публічного розкриття уразливості. На той момент у відкритому доступі ще не існувало готового PoC-експлойта, отже оператор атаки самостійно реалізував експлуатацію, спираючись лише на офіційний опис проблеми.
Після встановлення WebSocket-з’єднання зловмисник отримав оболонку, провів ручну розвідку файлової системи, переглядав структуру каталогів та перевіряв наявність чутливих даних. Основна увага була зосереджена на спробах прочитати вміст файлу .env, знайти SSH-ключі та інші файли з конфіденційною інформацією.
Протягом приблизно 90 хвилин атакувальник чотири рази повертався до honeypot-системи, роблячи перерви між сесіями. Такий патерн поведінки характерний для ручної роботи оператора, який послідовно проходить по списку цілей, перевіряє результати і фокусується передусім на крадіжці секретів та облікових даних. Ознак встановлення криптомайнерів, бекдорів чи масового шкідливого ПЗ зафіксовано не було.
Швидкість експлуатації уразливостей та ризики для open-source інструментів
Факт, що експлойт до Marimo був створений лише на основі тексту офіційного повідомлення про уразливість, без готового PoC, підкреслює тенденцію: професійним кіберзлочинцям достатньо мінімального технічного опису, щоб оперативно розробити робочий інструмент атаки. За оцінками гравців ринку кібербезпеки, медіанний час між публічним розкриттям критичної уразливості та її масовою експлуатацією скоротився з тижнів і днів до годин.
Чому менш відомі open-source сервіси теж прицільно атакують
Інцидент із Marimo спростовує поширене припущення, що зловмисників цікавлять лише найбільш масові платформи. Будь-який інтернет-доступний сервіс, для якого оприлюднено критичне повідомлення з безпеки, автоматично стає привабливою ціллю – незалежно від ринкової частки чи впізнаваності бренду.
Такі інструменти часто працюють у середовищах дослідження даних, лабораторіях машинного навчання та DevOps-інфраструктурі. На тих самих серверах можуть одночасно зберігатися ключі доступу до хмарних акаунтів, токени CI/CD, паролі до баз даних та інші високоцінні секрети. Тому навіть точковий компроміс одного сервісу здатний стати стартовою точкою для масштабної ескалації атаки всередині організації.
Рекомендації для адміністраторів Marimo та DevOps-команд
Негайне оновлення. Усі користувачі Marimo мають якнайшвидше оновитися щонайменше до версії 0.23.0. Важливо перевірити, що застарілі образи контейнерів із вразливими версіями не використовуються у тестових, тимчасових або допоміжних середовищах.
Обмеження мережевого доступу. Інстанси Marimo не слід відкривати безпосередньо в інтернет без суворої необхідності. Рекомендовано розміщувати сервіс за реверс-проксі, використовувати VPN, списки дозволених IP-адрес, а також повноцінні механізми автентифікації та авторизації (SSO, OAuth, корпоративні IdP).
Мінімізація поверхні атаки. Якщо функціональність вбудованого термінала не потрібна більшості користувачів, її доцільно вимкнути або обмежити доступ лише для адміністраторів. Адміністративні WebSocket-ендпоінти, зокрема пов’язані з оболонкою, мають бути закриті від зовнішніх мереж.
Захист секретів та облікових даних. Першочерговою метою зловмисника в кейсі з Marimo стали файли .env і SSH-ключі. Рекомендованою практикою є використання спеціалізованих сховищ секретів (Vault, KMS тощо), мінімізація кількості довгоживучих ключів, поділ прав доступу та регулярна ротація токенів.
Моніторинг та реагування на інциденти. Організаціям варто налаштувати збір і кореляцію логів WebSocket-з’єднань, відстежувати аномальну активність терміналів і оболонок у хмарних та контейнерних середовищах. При найменшій підозрі на компрометацію слід аналізувати журнали, відкликати потенційно скомпрометовані ключі й токени та проводити форензик-перевірку систем.
Кейс із CVE-2026-39987 в Marimo демонструє, що між публікацією критичної уразливості та її реальною експлуатацією сьогодні може минути менше десяти годин. Щоб зменшити це вікно ризику, організаціям необхідно будувати процеси оперативного управління уразливостями, автоматизувати розгортання патчів і регулярно переглядати перелік сервісів, доступних з інтернету. Чим менше часу має атакувальник і чим менше секретів зосереджено в одному сервісі, тим нижчі шанси, що інцидент із технічної проблеми переросте у повноцінну кризу для бізнесу.
