OpenLegion vs. nanobot: Was eine CVSS-10,0-Schwachstelle über Agenten-Sicherheit lehrt

nanobot ist wahrscheinlich die lehrreichste Fallstudie im KI-Agenten-Sicherheits-Bereich. Anfang 2026 von einem akademischen Forschungslabor geschaffen, destilliert es OpenClaws 430.000+ Codezeilen auf ca. 4.000 Zeilen Python — eine Code-Reduktion von 99 %, die 218 Punkte auf Hacker News einbrachte (die stärkste Resonanz aller Claw-Alternativen) und etwa 20.000–26.000 GitHub-Stars.

Innerhalb weniger Wochen nach dem Launch legten Sicherheitsforscher dann eine kritische Schwachstelle (CVSS 10,0) offen: Die WhatsApp-Bridge von nanobot band ihren WebSocket-Server an 0.0.0.0:3001 ohne jegliche Authentifizierung. Jeder im Netzwerk konnte WhatsApp-Sessions hijacken. Weitere kritische Schwachstellen folgten — Shell-Command-Injection, Path-Traversal-Bypass und eine Remote-Code-Execution-Lücke, die von einer LiteLLM-Abhängigkeit geerbt wurde.

nanobot ist ein gut gemeintes Lehrtool, das versehentlich zur Fallstudie wurde, warum leichter Code allein noch keinen sicheren Code ergibt. OpenLegion existiert, um diese Lektion strukturell zu machen.

OpenLegion ist ein sicherheitsorientiertes KI-Agenten-Framework mit verpflichtender Docker-Container-Isolation, Vault-Proxy-Credential-Verwaltung, Pro-Agent-Budgetdurchsetzung und Fleet-Modell-Koordination (Blackboard + Pub/Sub + Handoff).

Was ist der Unterschied zwischen OpenLegion und nanobot?

nanobot ist eine ca. 4.000-zeilige Python-Reimplementierung von OpenClaw mit Fokus auf pädagogische Einfachheit und Lesbarkeit. Es unterstützt 11+ LLM-Anbieter und 8+ Messaging-Kanäle, hat aber eine kritische WhatsApp-Bridge-Schwachstelle (CVSS 10,0, unauthentifizierter WhatsApp-Session-Hijack), Shell-Injection, Path-Traversal und LiteLLM-RCE-Schwachstellen erlitten. OpenLegion ist ein Security-First-Python-Framework mit verpflichtender Docker-Container-Isolation pro Agent, Vault-Proxy-Credential-Verwaltung (Agenten sehen nie API-Keys), Pro-Agent-Budgetdurchsetzung und Fleet-Modell-Koordination (Blackboard + Pub/Sub + Handoff). nanobot optimiert auf Lernen und Einfachheit; OpenLegion optimiert auf Produktions-Sicherheit.

Auf einen Blick

Dimension	OpenLegion	nanobot
Primärer Fokus	Produktions-Sicherheitsinfrastruktur	Pädagogische Einfachheit
Sprache	Python	Python (~4.000 Zeilen)
Agenten-Isolation	Docker-Container pro Agent, Non-Root	restrict_to_workspace-Flag (Anwendungs-Ebene)
Credential-Sicherheit	Vault-Proxy — Agenten sehen keine Keys	Config-Datei (~/.nanobot/config.json)
Budget-Kontrollen	Pro Agent tägliche/monatliche Hartabschaltung	Keine integriert
Orchestrierung	Fleet-Modell-Koordination (Blackboard + Pub/Sub + Handoff)	Einzelagent mit Hintergrund-Sub-Agenten
LLM-Anbieter	100+ über LiteLLM	11+ (OpenRouter, Anthropic, OpenAI, DeepSeek usw.)
Messaging-Kanäle	5	8+ (Telegram, Discord, WhatsApp, Feishu, DingTalk usw.)
Multi-Agent	Flotten-Templates mit Pro-Agent-ACLs	Sub-Agenten-Spawning (keine Flotten-Orchestrierung)
Memory	Persistent pro Agent mit Vektor-Suche	Grep-basierter Abruf (vermeidet bewusst RAG)
GitHub-Stars	~59	~20.000–26.000
Lizenz	PolyForm Perimeter License 1.0.1	MIT
Bekannte CVEs	0	kritische WhatsApp-Bridge-Schwachstelle (CVSS 10,0) + 3 weitere kritische Patches
Herkunft	Unabhängig	Akademisches Forschungslabor

Wählen Sie nanobot, wenn …

Sie lernen wollen, wie KI-Agenten funktionieren. nanobot ist ein Lehr-Skelett. Mit 4.000 Zeilen klarer Struktur ist es die beste Codebasis, um die zentrale Agenten-Schleife zu verstehen: Provider-Abstraktion, Tool-Dispatch, Memory-Retrieval und Chat-Gateways. DataCamp veröffentlichte ein vollständiges Tutorial. Die Schöpfer haben es explizit für pädagogische Lesbarkeit entworfen.

Sie brauchen Unterstützung für asiatische Messaging-Plattformen. nanobot hat erstklassige Unterstützung für Feishu (Lark), DingTalk, QQ und WeChat-nahe Plattformen — Kanäle, die kein westlich orientiertes Framework gut abdeckt. Wenn Ihr Deployment chinesische Enterprise-Messaging-Plattformen anvisiert, ist nanobots Ökosystem einzigartig positioniert.

Sie wollen Agenten auf einem Raspberry Pi betreiben. nanobot ist leicht genug für Single-Board-Computer. Kombiniert mit Ollama für lokale Inferenz erhalten Sie vollständig offline arbeitende Agenten.

Sie schätzen Einfachheit über Infrastruktur. JSON-Config, Grep-basiertes Memory (keine Vektor-Datenbank erforderlich) und pip install. Kein Docker, keine Fleet-Modell-Koordination, kein Vault-Setup. Von der Installation bis zum laufenden Agenten in unter fünf Minuten.

Community-Momentum zählt für Sie. nanobots 218-Punkte-HN-Launch, aktiver Discord, DataCamp-Integration und ~20.000+ Stars repräsentieren erhebliches Community-Investment und einen großen Pool von Contributors, die Issues schnell beheben (die CVSS 10,0 wurde innerhalb von Tagen gepatcht).

Wählen Sie OpenLegion, wenn …

Sicherheit muss architektonisch sein, nicht optional. nanobots restrict_to_workspace-Flag ist der primäre Isolationsmechanismus — ein Boolean, der ausgeschaltet werden kann. Seine API-Keys liegen in einer Klartext-JSON-Config-Datei. Sein WebSocket-Server wurde ohne Authentifizierung ausgeliefert. Das sind keine obskuren Randfälle; es sind fundamentale architektonische Entscheidungen, die innerhalb von Wochen eine CVSS 10,0 erzeugten. OpenLegion macht unsichere Konfigurationen strukturell unmöglich: Container-Isolation ist verpflichtend, der Vault-Proxy ist der einzige Credential-Pfad, und Fleet-Modell-Koordination ist durch Pro-Agent-Tool-Loop-Erkennung begrenzt.

Sie können sich keine CVSS 10,0 in Produktion leisten. Die kritische WhatsApp-Bridge-Schwachstelle erlaubte unauthentifizierten netzwerk-nahen Angreifern, WhatsApp-Sessions zu hijacken, indem sie sich mit nanobots ungeschütztem WebSocket-Server auf Port 3001 verbanden. Die zusätzlichen Shell-Injection- und Path-Traversal-Schwachstellen wurden von einem einzelnen Sicherheitsforscher in einem einzigen Audit gefunden. OpenLegions Vault-Proxy-Architektur bedeutet, dass es keine Credentials zum Hijacken gibt — Agenten rufen über einen Proxy, der Keys auf Netzwerkebene injiziert.

Sie brauchen Pro-Agent-Kostenkontrolle. nanobot hat keine Budgetdurchsetzung. Mit 11+ Provider-Unterstützung und der Fähigkeit, Hintergrund-Sub-Agenten zu spawnen, häufen sich unkontrollierte API-Ausgaben unbemerkt an. OpenLegion erzwingt tägliche und monatliche Pro-Agent-Limits mit automatischer Hartabschaltung.

Sie brauchen auditierbare Multi-Agenten-Flotten-Koordination. nanobot unterstützt das Spawnen von Sub-Agenten, aber die Orchestrierung ist LLM-getrieben und nicht-deterministisch. OpenLegions Fleet-Modell-Koordination definiert explizite Handoff-Records, Tool-Zugriff und Abhängigkeiten pro Agent — vor dem Deployment auditierbar.

Sie müssen Stakeholdern eine Sicherheitslage nachweisen. nanobots CVE-Historie macht es zu einer schwierigen Wahl für Sicherheits-Teams, Compliance-Reviewer oder Enterprise-Procurement. OpenLegions Vault-Proxy-Architektur, verpflichtende Container-Isolation und Pro-Agent-ACLs bieten nachweisbare Sicherheits-Kontrollen.

Vergleich der Sicherheitsmodelle

Wo Secrets liegen

nanobot speichert API-Keys in ~/.nanobot/config.json — einer Klartext-JSON-Datei auf der Festplatte. Die Config-Datei wurde anfangs mit 0644-Rechten (weltlesbar) geschrieben; das wurde später auf 0600 gepatcht. Zur Laufzeit werden Keys in den Python-Prozessspeicher geladen. Jeder Code, der im Agentenprozess ausgeführt wird, kann sie lesen.

OpenLegion speichert Credentials in einem Vault, auf den Agenten nicht zugreifen können. API-Aufrufe gehen über einen Vault-Proxy, der Credentials auf Netzwerkebene injiziert. Keine Config-Dateien mit Klartext-Keys, keine Umgebungsvariablen mit Secrets, keine gemounteten Credential-Dateien. Der Agentenprozess hält nie API-Keys.

Isolationsmodell

nanobot nutzt ein restrict_to_workspace-Flag, das Dateioperationen auf das Workspace-Verzeichnis begrenzt. Das ist eine Anwendungs-Level-Prüfung im Python-Code — wenn ein Agent beliebige Code-Ausführung erreicht (was die Shell-Injection-Schwachstelle als möglich zeigte), kann die Workspace-Beschränkung umgangen werden. Es wird keine OS-Level-Isolation erzwungen.

OpenLegion nutzt Docker-Container-Isolation pro Agent. Jeder Agent läuft in einem separaten Container mit Non-Root-Ausführung, ohne Docker-Socket-Zugriff, no-new-privileges und Pro-Container-Ressourcen-Caps. Selbst wenn ein Agent in seinem Container beliebige Code-Ausführung erreicht, kann er nicht auf andere Agenten, das Host-System oder Credential-Stores zugreifen.

Die CVE-Bilanz

nanobot hat in seiner kurzen Existenz erhebliche Sicherheitsprobleme angesammelt:

• kritische WhatsApp-Bridge-Schwachstelle (CVSS 10,0): WhatsApp-WebSocket-Bridge an 0.0.0.0:3001 ohne Authentifizierung gebunden. Netzwerk-nahe Angreifer konnten Sessions hijacken. Von Sicherheitsforschern entdeckt.
• Shell-Command-Injection (Medium): Unsanitisierte Nutzereingaben an Shell-Ausführung weitergegeben.
• Path-Traversal-Bypass (Medium): restrict_to_workspace ließ sich umgehen.
• LiteLLM-RCE via eval() (Kritisch): Von Abhängigkeit geerbt. Remote Code Execution über präparierte Eingaben.
• Session-Poisoning (gepatcht am 26. Februar 2026): Manipulation der Nachrichtenhistorie.

OpenLegion hat seit v0.1.0 keine CVEs gemeldet. Seine Architektur macht mehrere von nanobots Schwachstellen-Klassen strukturell unmöglich: Der Vault-Proxy eliminiert Credential-Exposition, Docker-Isolation verhindert Path-Traversal-Ausbrüche, und Fleet-Modell-Koordination verhindert beliebige Shell-Ausführung ohne explizite Tool-Grants.

Budget-Kontrollen

nanobot hat keine integrierten Ausgabenlimits. Hintergrund-Sub-Agenten können ohne Caps API-Aufrufe machen.

OpenLegion erzwingt tägliche und monatliche Pro-Agent-Limits mit automatischer Hartabschaltung.

nanobots Ökosystem: Was es am besten kann

Das Lehr-Skelett

nanobots größter Beitrag ist pädagogisch. Die zentrale Agenten-Schleife — Nachricht empfangen, Kontext abrufen, LLM aufrufen, Tools dispatchen, Antwort zurückgeben — liegt in sauberem, lesbarem Python offen. Die bewusste Wahl, Grep-basiertes Memory-Retrieval statt RAG zu nutzen, macht den Abrufmechanismus transparent. Die JSON-Config ist menschenlesbar. Jede architektonische Entscheidung priorisiert Verständnis über Raffinesse.

Für Studierende, Forscher und Entwickler, die lernen, wie KI-Agenten intern funktionieren, ist nanobot wohl der beste Startpunkt.

Asiatische Plattform-Integration

nanobots Channel-Unterstützung umfasst Feishu (Lark), DingTalk, QQ und Matrix — Plattformen, die chinesische Enterprise-Kommunikation dominieren. Kein anderes Framework im OpenClaw-Ökosystem bietet vergleichbare Abdeckung. Die akademische Herkunft des Projekts erklärt diesen Fokus wahrscheinlich, und sie repräsentiert echten Wert für Teams in asiatischen Märkten.

ClawHub-Skill-Kompatibilität

nanobot integriert sich mit dem ClawHub-Skill-Ökosystem und erhält damit Zugriff auf von der Community beigesteuerte Agenten-Skills. Das SKILL.md-Dokumentationsformat wird über nanobot, PicoClaw und andere Claw-Familien-Projekte hinweg geteilt.

Die Rapid-Response-Kultur

Als die kritische WhatsApp-Bridge-Schwachstelle offengelegt wurde, patchte das nanobot-Team sie innerhalb von Tagen. Der Session-Poisoning-Fix landete am 26. Februar. Shell-Injection und Path-Traversal wurden schnell adressiert. Die Reaktionsfähigkeit der Community ist beeindruckend — sie unterstreicht aber auch, dass die Probleme erst gar nicht hätten ausgeliefert werden sollen.

Häufige Produktions-Stolperfallen

Das fundamentale Problem ist architektonisch. nanobot wurde als Lehrtool entworfen und produktiv populär. Sein Sicherheitsmodell — Anwendungs-Level-Workspace-Beschränkung, Klartext-Config, keine Netzwerk-Isolation — ist für lokales Experimentieren angemessen, aber in Produktion gefährlich. Die CVSS 10,0 war kein Bug in komplexem Code; es war ein WebSocket-Server ohne Authentifizierung. Genau diese Art von Versäumnis verhindern architektonische Sicherheits-Constraints.

Abhängigkeitsketten-Risiko. Der LiteLLM-RCE (via eval()) zeigt, dass selbst minimale Codebasen Schwachstellen von ihren Abhängigkeiten erben. nanobots ~4.000 Zeilen sind auditierbar, aber der vollständige Abhängigkeitsbaum nicht.

Kein Netzwerk-Sicherheitsmodell. nanobot hat kein Konzept von Netzwerk-Policies, Ingress-Kontrollen oder Service-Mesh-Isolation. Agenten können beliebige ausgehende Verbindungen herstellen. Kombiniert mit Shell-Zugriff schafft das eine weite Angriffsfläche.

Was OpenLegion anders abdeckt

OpenLegions Architektur verhindert nanobots Schwachstellen-Klassen by design:

• Kritische WhatsApp-Bridge-Schwachstelle (unauthentifizierter Netzwerkdienst): OpenLegion-Agenten laufen in Docker-Containern mit standardmäßig keinen exponierten Ports. Netzwerkzugriff wird pro Agent explizit gewährt.
• Shell-Injection: OpenLegions Fleet-Modell-Koordination erfordert explizite Tool-Grants. Shell-Zugriff ist nicht verfügbar, sofern nicht in der ACL des Agenten gezielt aktiviert.
• Path-Traversal: Docker-Container-Isolation mit Read-only-Mounts und ohne Docker-Socket eliminiert Path-Traversal als sinnvollen Angriffsvektor.
• Credential-Exposition: Vault-Proxy bedeutet, dass keine Credentials in der Agentenumgebung zum Diebstahl existieren.
• Abhängigkeits-RCE: Container-Isolation begrenzt den Blast Radius — selbst wenn eine Abhängigkeit einen RCE hat, ist der Angreifer in einem gesandboxten Container ohne Credentials eingeschlossen.

Hosting- vs. Self-Host-Kompromisse

nanobot ist für lokales Self-Hosting entworfen. pip install, JSON-Config und ein laufender Agent in Minuten. Es gibt keinen gehosteten Dienst. Die leichte Natur bedeutet, dass jedes Linux-System, macOS oder sogar ein Raspberry Pi es hosten kann.

OpenLegion benötigt Python, SQLite und Docker. Die gehostete Plattform (kommt bald) wird Per-User-VPS-Instanzen für 19 $/Monat bieten. Das Docker-Erfordernis ergänzt Infrastruktur-Overhead, liefert aber die Isolations-Schicht, die Produktions-Deployment sicher macht.

Für wen

nanobot ist für Studierende, Forscher und einzelne Entwickler, die KI-Agenten-Architektur durch eine saubere, lesbare Codebasis verstehen wollen. Es ist auch wertvoll für Teams, die asiatische Messaging-Plattformen (Feishu, DingTalk, QQ) anvisieren. Der ideale Nutzer betreibt nanobot lokal für persönliche Aufgaben und exponiert es nicht in untrusted Netzwerken.

OpenLegion ist für Engineering-Teams, die Agenten in Umgebungen ausspielen, in denen Sicherheitsvorfälle geschäftliche Konsequenzen haben. Der ideale Nutzer muss Stakeholdern Credential-Isolation, Kostenkontrolle und Audit-Trails nachweisen — und kann sich keine CVSS 10,0 in Produktion leisten.

Der ehrliche Kompromiss

nanobot beweist, dass man eine KI-Agenten-Runtime in 4.000 Zeilen neu bauen kann. Diese Leistung ist real und wertvoll fürs Ökosystem. Aber die kritische WhatsApp-Bridge-Schwachstelle beweist, dass Einfachheit und Sicherheit nicht dasselbe sind. Eine 4.000-zeilige Codebasis mit einer CVSS 10,0 ist weniger sicher als eine ~77.000-zeilige Codebasis mit architektonischen Constraints, die diese Schwachstellen-Klasse unmöglich machen.

Wenn Sie lernen wollen, wie Agenten funktionieren, lesen Sie nanobots Quellcode. Wenn Sie Agenten sicher ausspielen wollen, nutzen Sie ein Framework, in dem unsichere Konfigurationen nicht vorkommen können.

Für die gesamte Landschaft siehe unseren KI-Agenten-Frameworks-Vergleich.

Häufig gestellte Fragen

Was ist nanobot?

nanobot ist eine ca. 4.000-zeilige Python-Reimplementierung von OpenClaw, geschaffen von einem akademischen Forschungslabor. Es unterstützt 11+ LLM-Anbieter und 8+ Messaging-Kanäle (darunter asiatische Plattformen wie Feishu, DingTalk und QQ). Es startete am 2. Februar 2026 und hat ca. 20.000–26.000 GitHub-Stars. Es erhielt die stärkste Hacker-News-Resonanz aller OpenClaw-Alternativen (218 Punkte, 111 Kommentare).

OpenLegion vs. nanobot: Was ist der Unterschied?

nanobot ist ein pädagogisches Lehr-Skelett — minimal, lesbar und zum Lernen entworfen. OpenLegion ist ein Produktions-Sicherheits-Framework. nanobot nutzt Anwendungs-Level-Workspace-Beschränkung und Klartext-JSON-Config; OpenLegion nutzt Docker-Container-Isolation und Vault-Proxy-Credentials. nanobot hat eine kritische WhatsApp-Bridge-Schwachstelle (CVSS 10,0) plus drei weitere kritische Schwachstellen erlitten; OpenLegion hat seit v0.1.0 keine CVEs gemeldet und eine Architektur, die diese Schwachstellen-Klassen strukturell unmöglich macht.

Ist OpenLegion eine nanobot-Alternative?

Ja. Beide sind Python-basierte KI-Agenten-Frameworks, sie dienen aber unterschiedlichen Zwecken. nanobot ist am besten zum Lernen und für lokales Experimentieren. OpenLegion ist eine Alternative für Teams, die produktionsgrade Sicherheit brauchen — Vault-Proxy-Credential-Isolation, Pro-Agent-Budgetdurchsetzung, Docker-Container-Isolation und Fleet-Modell-Koordination (Blackboard + Pub/Sub + Handoff).

Wie vergleicht sich Credential-Handling zwischen OpenLegion und nanobot?

nanobot speichert API-Keys in ~/.nanobot/config.json (bis zum Patch anfangs weltlesbar). Keys werden zur Laufzeit in den Python-Prozessspeicher geladen. OpenLegion nutzt einen Vault-Proxy — Agenten führen API-Aufrufe über einen Proxy aus, der Credentials auf Netzwerkebene injiziert. Agenten halten, lesen oder erreichen API-Keys in keiner Form.

Welches ist besser für Produktions-KI-Agenten?

OpenLegion ist deutlich besser für die Produktion geeignet. nanobot wurde als Lehrtool entworfen und hat innerhalb von Wochen nach dem Launch eine kritische WhatsApp-Bridge-Schwachstelle (CVSS 10,0), Shell-Injection, Path-Traversal und Abhängigkeits-RCE-Schwachstellen angesammelt. OpenLegions verpflichtende Container-Isolation, Vault-Proxy-Credentials, Pro-Agent-Budgets und auditierbare Fleet-Modell-Koordination adressieren genau die Schwachstellen-Klassen, die nanobot betroffen haben.

Ist nanobot dasselbe wie nanobot (Obot AI)?

Nein. Es gibt zwei völlig unterschiedliche Projekte mit demselben Namen. Das auf dieser Seite besprochene nanobot ist eine ca. 4.000-zeilige Python-OpenClaw-Alternative aus einem akademischen Forschungslabor. Obot AIs nanobot ist eine Go-basierte MCP-Agenten-Plattform mit 35 Mio. $ Seed-Funding vom Rancher-Labs-Team. Diese Seite vergleicht OpenLegion mit der Python-OpenClaw-Alternativ-Version.

Was war nanobots kritische WhatsApp-Bridge-Schwachstelle?

nanobots WhatsApp-Bridge enthielt eine kritische Schwachstelle (CVSS 10,0), bei der der WebSocket-Server an 0.0.0.0:3001 ohne jegliche Authentifizierung gebunden war. Jeder netzwerk-nahe Angreifer konnte sich verbinden und aktive WhatsApp-Sessions hijacken. Es wurde schnell gepatcht, demonstriert aber das Risiko, Agenten-Frameworks ohne architektonische Netzwerk-Isolation auszuspielen.

Kann ich von nanobot zu OpenLegion migrieren?

nanobots JSON-Config und Agenten-Setup würden als Fleet-Modell-Koordination mit expliziten Tool-Grants, Budget-Limits und Pro-Agent-ACLs restrukturiert. LLM-Provider-Einstellungen werden direkt übertragen, da beide LiteLLM-kompatible Provider-Konfigurationen nutzen. Siehe unsere Seite zur KI-Agenten-Orchestrierung.

---

Verwandte Vergleiche

Anchor-Text	Ziel
OpenLegion vs. NanoClaw	/comparison/nanoclaw
OpenLegion vs. PicoClaw	/comparison/picoclaw
OpenLegion vs. ZeroClaw	/comparison/zeroclaw
OpenLegion vs. OpenClaw	/comparison/openclaw
KI-Agenten-Frameworks-Vergleich 2026	/learn/ai-agent-frameworks
KI-Agenten-Sicherheits-Analyse	/learn/ai-agent-security