Moltbot (früher Clawdbot) hat in wenigen Wochen über 93.000 GitHub-Sterne gesammelt und zählt damit zu den am schnellsten wachsenden Open-Source-KI-Projekten des Jahres 2026. Der Assistent integriert sich in WhatsApp, Telegram, Slack, Discord und weitere Plattformen und wird als „persönliche KI auf eigener Hardware“ beworben. Genau diese tiefe Integration in die digitale Lebens- und Arbeitsumgebung macht Moltbot jedoch zu einem attraktiven Angriffsziel für Cyberkriminelle.
Moltbot: Leistungsstarker KI-Agent mit tiefem Systemzugriff
Vom Chatbot zum autonomen Assistenten
Im Unterschied zu klassischen Chatbots agiert Moltbot proaktiv. Er verwaltet Kalender, erinnert an Aufgaben, führt eine Langzeitgedächtnis-Datenbank in Markdown und SQLite und kann im Hintergrund Browser, E-Mail-Postfächer und lokale Dateien steuern. Anwender lagern dem Agenten damit sensible Aufgaben aus – von geschäftlicher Kommunikation bis hin zu Zugangsdaten für Cloud-Dienste.
Angriffsoberfläche durch weitreichende Berechtigungen
Um diese Autonomie zu ermöglichen, benötigt Moltbot unter anderem API-Schlüssel für kommerzielle LLMs (z.B. Claude Opus 4.5), Zugriff auf Messenger und E-Mails, OAuth-Tokens, Konten externer Services und teils sogar die Berechtigung zur Ausführung von Shell-Kommandos. Aus Sicht der IT-Sicherheit entsteht damit ein klassisches „Single Point of Failure“: Wird Moltbot kompromittiert, erhält ein Angreifer häufig Vollzugriff auf die gesamte Arbeitsumgebung. Studien wie der Verizon Data Breach Investigations Report zeigen seit Jahren, dass gestohlene Zugangsdaten zu den häufigsten Einfallsvektoren gehören – KI-Agenten bündeln diese besonders stark an einem Ort.
Kompromittierung durch gefälschte Tools und Fehlkonfigurationen
VS-Code-Erweiterung als Einfallstor für Remote-Zugriff
Die Sicherheitsfirma Aikido identifizierte im Visual-Studio-Code-Marktplatz eine bösartige Erweiterung namens „ClawdBot Agent — AI Coding Assistant“, die sich fälschlich als offizielles Moltbot-Tool ausgab. Ein legitimes VS-Code-Plugin existiert für Moltbot nicht. Nach der Installation startete die Erweiterung automatisch mit jeder VS-Code-Sitzung, lud eine externe config.json und führte ein Binary Code.exe aus, das den legitimen Remote-Access-Dienst ScreenConnect installierte – hier jedoch als persistente Hintertür missbraucht.
Die Entwicklerrechner verbanden sich damit zu den Servern der Angreifer, die dauerhaft Fernzugriff erhielten. Fallback-Mechanismen über alternative Domains und Dropbox-DLLs erhöhten die Robustheit der Infrastruktur. Microsoft entfernte das Plugin zwar, doch ist unklar, wie viele Entwickler den Markenvertrauen in Moltbot ausgenutzt bekamen und die Erweiterung bereits installiert hatten.
Offene Moltbot-Instanzen durch fehlerhafte Proxy-Konfiguration
Der Sicherheitsforscher Jamison O’Reilly (Dvuln) fand weltweit Hunderte öffentlich erreichbare Moltbot-Instanzen ohne jegliche Authentifizierung. Ursache war eine typische Fehlkonfiguration: Reverse Proxys vertrauten allen „lokalen“ Verbindungen – bei falschem Setup wurde externer Traffic als intern eingestuft. Über diese offenen Management-Oberflächen ließen sich API-Schlüssel, OAuth-Tokens, Chat-Historien und Konfigurationen auslesen und Kommandos ausführen.
In Stichproben identifizierte O’Reilly mindestens acht vollständig ungeschützte Installationen, darunter einen Server mit integrierter Signal-Anbindung, vollständigem Lesezugriff und aktiven Verknüpfungs-URIs bzw. QR-Codes zur Kopplung neuer Geräte. Ein solcher Zugriff entspricht aus Angreifersicht einem vollständigen Account-Takeover.
Supply-Chain-Risiken in der MoltHub-Plugin-Ökosphäre
Parallel demonstrierte O’Reilly ein Proof-of-Concept gegen MoltHub, das Skill-Repository von Moltbot. Ein harmloser Test-Skill mit simplen „ping“-Funktionen wurde veröffentlicht, der Downloadzähler künstlich auf über 4.000 erhöht und danach reale Nutzung in mindestens sieben Ländern festgestellt. In einem echten Angriff könnte ein solches Modul im Hintergrund SSH-Schlüssel, Cloud-Credentials (z.B. AWS) oder Quellcode exfiltrieren – ein klassischer Supply-Chain-Angriff, wie er bereits bei Paketmanagern wie NPM oder PyPI beobachtet wurde.
Lokale Datenspeicherung: Vom Helfer zum versteckten Backdoor
Eine Analyse von Hudson Rock zeigt, dass Moltbot einen Teil seiner Geheimnisse im Klartext speichert – etwa in Markdown- und JSON-Dateien auf dem Hostsystem. Gerät der Rechner unter Kontrolle eines gängigen Infostealers (z.B. Redline, Lumma oder Vidar), kann der Angreifer diese Dateien ohne weitere Hürden auslesen. Damit werden sämtliche Tokens, Schlüssel und Gesprächsverläufe des KI-Agenten unmittelbar kompromittiert.
Hinzu kommt: Malware-Familien passen sich bereits an die Verzeichnisstruktur von Moltbot an. Verfügt ein Angreifer über Schreibrechte, kann er Konfigurationsdateien manipulieren und den Assistenten in eine vertrauenswürdige Backdoor verwandeln, die unbemerkt Daten an externe Endpunkte sendet oder Befehle ausführt. Aus Sicht von Zero-Trust-Architekturen (vgl. NIST SP 800‑207) widerspricht ein derart privilegierter Agent praktisch allen Prinzipien der minimalen Rechtevergabe.
Lehren für die Sicherheit von KI-Agenten
Sicherheitsexperten von Anbietern wie Salt Security und Intruder betonen die Diskrepanz zwischen Hype und Sicherheitsrealität. Moltbot ist für schnelle Inbetriebnahme optimiert, nicht für „secure by default“. Es fehlen verpflichtende Firewalls, starke Authentifizierungsmechanismen und robuste Sandboxen für Plugins. Einige Forscher sprechen deshalb zugespitzt von einem „Infostealer im Gewand eines KI-Assistenten“.
In der Praxis versuchen technisch versierte Nutzer, das Risiko zu reduzieren, indem sie Moltbot auf dedizierter Hardware betreiben – etwa einem isolierten Mac Mini mit eigenen E-Mail-Konten und separaten Passwort-Tresoren, quasi wie ein zusätzlicher, streng abgegrenzter Mitarbeiter. Diese Strategie senkt das Schadenspotenzial, ändert jedoch nichts am Kernproblem: Jeder hochprivilegierte KI-Agent bündelt kritische Berechtigungen und wird damit zur Konzentrationsstelle systemischer Risiken.
Wer Moltbot oder ähnliche KI-Agenten für geschäftliche oder private Zwecke einsetzt, sollte sie daher wie Admin-Konten und kritische Infrastruktur behandeln: Betrieb auf isolierten Hosts oder in abgeschotteten Segmenten, konsequente Umsetzung des Prinzips der geringsten Privilegien, Härtung von Reverse Proxys, strikte Zugangskontrolle zu Management-Oberflächen, sorgfältige Prüfung von Plugins und Skills, kontinuierlicher Log- und Konfigurations-Audit sowie ein klarer Incident-Response-Plan. Der Aufwand für eine durchdachte Sicherheitsarchitektur beim Rollout eines KI-Assistenten ist in der Regel deutlich geringer als die Kosten einer späteren Kompromittierung – insbesondere, wenn der Angreifer über den Agenten Zugriff auf die gesamte digitale Identität seiner Opfer erlangt.
