Moltbot (раніше Clawdbot) менш ніж за місяць зібрав понад 93 000 зірок на GitHub і став одним із найдинамічніших open-source AI‑проєктів 2026 року. Це «персональний ІІ‑асистент, який працює на вашому залізі», здатний інтегруватися з WhatsApp, Telegram, Slack, Discord та іншими сервісами. Водночас саме глибокий доступ до цифрового життя користувача перетворив Moltbot на привабливу ціль для кіберзлочинців.
Функціональність Moltbot і концентрація привілеїв
Moltbot позиціонується не як пасивний чат‑бот, а як автономний AI‑агент. Він самостійно нагадує про задачі, синхронізується з календарем, веде довгострокову пам’ять у форматах Markdown та SQLite, може керувати браузером, електронною поштою та локальними файлами у фоновому режимі. Фактично користувач делегує йому значну частину рутинних дій та доступ до чутливих даних.
Для повноцінної роботи Moltbot потребує API‑ключі до комерційних LLM (наприклад, Claude Opus 4.5), доступ до мессенджерів і пошти, OAuth‑токени, облікові записи сторонніх сервісів, а в окремих сценаріях — право виконання shell‑команд. Така концентрація привілеїв створює типову ситуацію «single point of failure»: одна компрометація інстансу Moltbot дає атакувальнику фактично повний доступ до цифрового оточення власника.
Шкідливе розширення VS Code: маскування під офіційний інструмент Moltbot
Підроблений ClawdBot Agent і приховане встановлення ScreenConnect
Компанія Aikido виявила у Visual Studio Code Marketplace розширення «ClawdBot Agent — AI Coding Assistant», яке імітувало офіційний інструмент для інтеграції з Moltbot. Насправді ж у проєкту не існує легітимного плагіна для VS Code, а розширення виконувало шкідливі дії.
Після встановлення модуль автоматично запускався при кожному старті IDE, завантажував файл config.json з віддаленого сервера та запускав бінарний файл Code.exe. Останній встановлював легальний, але у цьому випадку зловживаний продукт віддаленого доступу ScreenConnect, підключаючи систему розробника до інфраструктури операторів атаки.
Таким чином зловмисники отримували стійкий віддалений контроль над робочою станцією. Для підвищення надійності атаки використовувались резервні механізми: за недоступності основного сервера шкідливий код підвантажував DLL‑файли з Dropbox або альтернативних доменів. Microsoft видалила розширення, однак невідомо, скільки розробників встигли його встановити, поклавшись на впізнаваність бренду Moltbot.
Небезпечні конфігурації Moltbot та витік API‑ключів
Помилки reverse proxy й відкриті панелі керування
Дослідник Джеймісон О’Рейлі (Dvuln) виявив сотні публічно доступних інстансів Moltbot, що не вимагали автентифікації. Причиною стала типова помилка налаштування: reverse proxy «за замовчуванням» довіряв усім «локальним» підключенням, а через некоректний мапінг мережі будь‑який зовнішній трафік сприймався як довірений.
Через такі відкриті панелі керування зловмисник міг переглядати та експортовано отримувати API‑ключі, OAuth‑токени та історію діалогів, виконувати команди від імені асистента та перехоплювати облікові дані. Під час ручної перевірки дослідник знайшов щонайменше вісім повністю незахищених установок, включно з сервером, де був інтегрований Signal із повним доступом до історії листування та активними URI/QR‑кодами для додавання нових пристроїв.
Уразливості MoltHub і ризики ланцюга постачання
Паралельно О’Рейлі провів proof‑of‑concept атаку на MoltHub — репозиторій «skills» для Moltbot. Він опублікував безпечний модуль з мінімальною функціональністю «ping» і штучно накрутив лічильник завантажень понад 4000 разів. Логи засвідчили реальне використання цього пакета розробниками щонайменше з семи країн.
У реальній атаці подібний модуль міг би непомітно ексфільтрувати SSH‑ключі, облікові дані AWS та фрагменти вихідного коду, демонструючи вразливість екосистеми плагінів та ланцюга постачання AI‑агентів. Довіра до «популярних» skills без незалежного аудиту відкриває шлях до цілеспрямованих атак на розробників і організації.
Зберігання секретів, інфостилери та перетворення AI‑асистента на бекдор
За даними команди Hudson Rock, Moltbot зберігає частину конфіденційних даних у незашифрованому вигляді — у Markdown‑ та JSON‑файлах на локальній машині. Для звичайних інфостилерів (RedLine, Lumma, Vidar тощо) це спрощує задачу: достатньо зчитати вміст відомих директорій, щоб отримати ключі, токени та історію взаємодій з ІІ‑агентом.
Дослідники також фіксують, що сучасні зразки малварі вже адаптуються до структури каталогів Moltbot. За наявності прав на запис зловмисник може модифікувати конфігураційні файли, додати довіру до власних endpoint‑ів, активувати автоматичне відправлення даних або виконання довільних команд. У такому сценарії Moltbot фактично стає бекдором із підвищеними привілеями, який працює «за правилами», але на користь атакувальника.
Ребрендинг Clawdbot → Moltbot і криптоскам навколо токена $CLAWD
Окремий вектор зловживань стосується бренду. На запит Anthropic розробник був змушений перейменувати проєкт з Clawdbot на Moltbot через подібність до назви Claude. У момент зміни GitHub‑організації та ніка в X (Twitter) криптозловмисники тимчасово перехопили контроль над старими обліковками та почали агресивно просувати фейковий токен $CLAWD.
Ринкова капіталізація псевдокоїна, за оцінками, сягнула близько 16 млн доларів США, після чого токен фактично знецінився. Петер Штайнбергер публічно заявив, що не має стосунку до жодних криптопроєктів із його ім’ям, і назвав такі ініціативи скамом. Інцидент показує, наскільки швидко популярність open-source‑проєкту може бути використана для соціальної інженерії та фінансових шахрайств.
AI‑агенти як новий клас критичних активів безпеки
Фахівці Salt Security та Intruder звертають увагу на розрив між ентузіазмом користувачів і реальними вимогами до безпеки. Архітектура Moltbot орієнтована на швидке розгортання, а не на принцип secure by default: немає обов’язкових файрволів, жорсткої перевірки облікових даних та ізоляції плагінів. Водночас AI‑агентам за визначенням потрібні широкі привілеї — доступ до файлів, секретів, виконання команд і взаємодія з зовнішніми сервісами, що прориває традиційні бар’єри захисту (песочниці, сегментація, моделі дозволів).
Частина технічних користувачів намагається зменшити ризики, розгортаючи Moltbot на виділеному хості — наприклад, окремому Mac Mini з власними обліковими записами пошти та менеджера паролів, як для нового співробітника. Це справді зменшує потенційний радіус ураження, але не усуває головної проблеми: будь‑який високо привілейований AI‑агент залишається критичною точкою концентрації ризиків.
Кейс Moltbot демонструє, що AI‑асистентів із доступом до корпоративних чи персональних даних потрібно розглядати як адміністраторські облікові записи або елементи критичної інфраструктури. Практичні кроки включають виділені хости, принцип найменших привілеїв, жорсткий контроль reverse proxy, мінімізацію й регулярну ротацію API‑ключів, аудит конфігурацій, моніторинг логів та ретельну перевірку розширень і skills. Інвестиції у безпечну архітектуру на етапі впровадження AI‑агента майже завжди виявляються дешевшими за ліквідацію наслідків його компрометації.
