Хакери бяха забелязани да експлоатират критична уязвимост за отдалечено изпълнение на код (RCE) в платформата за интерактивни тетрадки Marimo, за да откраднат AWS идентификационни данни и да се автентифицират пред SSH бастионен хост в рамките на едва осем секунди.

Атаката, документирана от екипа за изследване на заплахи на Sysdig, се възползва от CVE-2026-39987 — уязвимост за отдалечено изпълнение на код преди автентификация, засягаща версии на Marimo до 0.20.4 включително. Проблемът с сигурността е коригиран във версия 0.23.0 на Marimo.

Marimo е платформа с отворен код за реактивни Python тетрадки, често използвана от разработчици, специалисти по данни (data scientists) и екипи за машинно обучение.

Тъй като сървърите с тетрадки могат да работят съвместно с облачни работни товари, набори от данни, API токени и инструменти за разработка, компрометирането им може да предостави на атакуващите ценен достъп до чувствителни среди.

Уязвимият компонент е терминалната WebSocket крайна точка на Marimo. Изследователите посочват, че крайната точка не е прилагала правилно проверките за автентификация.

Атакуващ би могъл да отвори WebSocket връзка и да получи интерактивна обвивка (shell) от името на потребителя, изпълняващ процеса на Marimo, без да притежава валидни идентификационни данни.

RCE в Marimo позволява кражба на AWS идентификационни данни за 8 секунди

В наблюдаваната атака киберпрестъпникът е използвал специализирани персонализирани инструменти, а не агент с изкуствен интелект или голям езиков модел. Въпреки ръчния подход, той се е придвижвал със скорост на машина през компрометираната среда.

От Sysdig са установили, че са изминали едва осем секунди между отварянето на нова WebSocket сесия и успешната автентификация чрез SSH към бастионен хост по веригата.

След получаване на достъп до сървъра на Marimo, атакуващият е потърсил облачни идентификационни данни, изложени чрез хост средата и Redis услугата на приложението. След това киберпрестъпникът е използвал откраднатите AWS идентификационни данни, за да направи заявка към AWS Secrets Manager.

Заявката към Secrets Manager е върнала частен SSH ключ. Атакуващ субект незабавно е използвал този ключ, за да се автентифицира пред достъпен от интернет SSH бастионен хост (известен още като jump server).

Бастионните хостове често се използват като контролирани входни точки за администратори, осъществяващи достъп до системи в частни облачни мрежи. Тяхното компрометиране може да осигури на атакуващите директен маршрут до вътрешните ресурси.

Бързото преминаване от откраднати данни към бастионен хост показва защо правата на достъп в облака трябва да бъдат строго ограничени. Дадена инстанция с тетрадка не трябва да разполага с широки разрешения за четене на тайни, непреки за нейната нормална работа.

В този случай наличните идентификационни данни на компрометирания Marimo хост са осигурили достъп до SSH ключ, позволяващ хоризонтално придвижване (lateral movement) в друга част от средата.

Инцидентът подчертава и опасността от публично изложени инфраструктури за разработка и машинно обучение. Екипите често внедряват бързо сървъри с тетрадки за експерименти.

Въпреки това те могат да запазят достъп до AWS услуги, изходен код, набори от данни, credentials за доставчици на модели и вътрешни системи. Една единствена неохранявана услуга без автентификация може да се превърне във входна точка за много по-мащабен пробив в облачната среда.

Организациите, използващи Marimo, трябва незабавно да актуализират до версия 0.23.0 или по-нова. Екипите по сигурност трябва също така да идентифицират публично достъпните инсталации на Marimo, да деактивират или защитят ненужните терминални крайни точки и да гарантират, че WebSocket услугите изискват автентификация.

AWS администраторите трябва да прегледат IAM правата, прикрепени към работните товари с тетрадки, особено достъпа до AWS Secrets Manager. Идентификационните данни трябва да следват принципа на минималните привилегии и не трябва да могат да извличат несвързани SSH ключове, производствени тайни или токени за достъп с висока стойност.

Екипите трябва да подменят (ротират) AWS идентификационните данни, SSH ключовете, API токените и други тайни, които може да са били изложени на уязвимите инстанции.

Мониторингът трябва да се фокусира върху необичайни заявки към Secrets Manager, неочаквано използване на идентификационни данни, нови SSH автентификации към бастионни хостове и бързи последователности от облачни API активности след осъществен достъп до приложението.

Атаката показва, че ръчно управлявана кибератака може да изпълни пълната верига от експлоатация до хоризонтално придвижване за броени секунди, когато облачните идентификационни данни и привилегированите тайни са оставени лесно достъпни.

Научете 7-те фази за внедряване на AI SOC, базирани на метрики – изтеглете безплатния AI SOC Deployment Playbook 2026.