OpenClaw: Potenzial und Risiken autonomer Agenten

OpenClaw ist in weniger als 72 Stunden auf 60.000 GitHub Stars geschossen, eine Geschwindigkeit, die selbst für Open-Source-Verhältnisse außergewöhnlich ist. Das Tool verspricht, autonome KI-Agenten mit lokalen Dateien, Messaging-Apps und beliebigen Automatisierungen zu verbinden. Gleichzeitig häufen sich die Sicherheitsmeldungen. Fünf kritische CVEs, über 40.000 exponierte Instanzen und koordinierte Supply-Chain-Angriffe über den eigenen Marketplace zeigen: Das Bild ist deutlich komplizierter als der erste Hype vermuten lässt.

Was ist OpenClaw?

OpenClaw ist ein selbst gehosteter, autonomer KI-Assistent. Der österreichische Entwickler Peter Steinberger startete das Projekt im November 2025 unter dem Namen “Clawdbot”. Nach einer Trademark-Auseinandersetzung mit Anthropic (die das Projekt kurz zu “Moltbot” umbenannten) läuft es seit dem 30. Januar 2026 unter dem Namen OpenClaw.

Die Kernidee besteht darin, dass KI-Modelle nicht als abgeschottete Chat-Schnittstellen betrieben werden, sondern mit echten Ressourcen verbunden sind. Das umfasst lokale Dateisysteme, Messaging-Dienste wie WhatsApp und Discord sowie beliebige Automatisierungsworkflows. Agenten können damit selbstständig Aufgaben planen, Dateien lesen und schreiben, Nachrichten senden und Code ausführen.

Im Februar 2026 wechselte Steinberger zu OpenAI. Das Projekt wurde an eine Open-Source-Foundation übergeben und wird seitdem von der Community weiterentwickelt.

Das erklärt einen Teil des Hypes. OpenClaw trifft einen echten Bedarf: Wer autonome Agenten lokal betreiben will, ohne Daten an externe Cloud-Dienste zu schicken, findet hier eine funktionsfähige und erweiterbare Basis. Ähnliche Anforderungen diskutieren wir ausführlich in unserem Artikel über KI-Agenten im Enterprise-Einsatz.

Was OpenClaw technisch kann

Die Architektur von OpenClaw besteht aus drei Schichten:

Bei der Modell-Anbindung unterstützt OpenClaw verschiedene LLM-Backends. Von OpenAI-kompatiblen APIs bis zu lokal laufenden Modellen via Ollama oder LM Studio ist alles möglich. Die Konfiguration erfolgt über eine zentrale config.yaml.

Das Tool-System basiert auf einem Plugin-System, den sogenannten “Skills”. Über sie lassen sich externe Dienste und lokale Ressourcen anbinden. Der ClawHub Marketplace bietet fertige Skills für gängige Anwendungsfälle wie Dateioperationen, Kalender-Integration und Webhooks.

Der Agenten-Loop ist das Kernstück. Der Agent plant Schritte, führt sie aus, prüft die Ergebnisse und passt seinen Plan an. Das Verhalten ähnelt dem, was Frameworks wie LangGraph oder AutoGen bieten, läuft aber als einzelner Self-Hosted-Dienst ohne externe Abhängigkeiten.

# Beispiel: config.yaml
agent:
  model: "gpt-4o"
  system_prompt: "Du bist ein autonomer Assistent für..."
  tools:
    - filesystem
    - discord
    - calendar
  max_iterations: 20
  token_budget: 50000

Für Entwickler und kleine Teams, die schnell eine autonome Lösung aufsetzen wollen, ist das technisch attraktiv. Die Einstiegshürde ist niedrig, die Dokumentation gut gepflegt.

Die Sicherheitslage: Fünf kritische CVEs

Mit dem schnellen Wachstum kamen die Schwachstellen. Innerhalb weniger Wochen nach dem initialen Hype wurden fünf kritische CVEs veröffentlicht:

CVE	Typ	CVSS
CVE-2026-25253	Token Leakage via Gateway-URLs	9.1
CVE-2026-24763	Remote Command Injection	9.8
CVE-2026-26322	Server-Side Request Forgery (SSRF)	8.6
CVE-2026-26329	Local File Exposure (Path Traversal)	8.2
CVE-2026-30741	Code Execution via Prompt Injection	9.3

CVE-2026-24763 und CVE-2026-30741 sind besonders kritisch. Remote Command Injection erlaubt Angreifern, über manipulierte Eingaben beliebige Befehle auf dem Host-System auszuführen. Die Prompt-Injection-Schwachstelle ist noch perfider, da ein Angreifer über präparierte Dokumente oder Nachrichten den Agenten dazu bringen kann, Befehle auszuführen. Dies geschieht ohne direkten Zugriff auf das System.

Sicherheitsforscher der CERT/CC haben Mitte Februar 2026 eine Analyse veröffentlicht, die zeigt: 40.000+ öffentlich erreichbare OpenClaw-Instanzen wurden identifiziert. 35-63% davon laufen auf ungepatchten Versionen. 12.812 Instanzen gelten als anfällig für Remote Code Execution.

Supply-Chain-Angriffe über den Marketplace

Neben den Kern-CVEs gibt es ein strukturelles Problem: den ClawHub Marketplace.

Zwischen 341 und 824 dokumentierte bösartige Skills wurden im Marketplace hochgeladen. Die Zahlen variieren je nach Zeitpunkt der Erhebung, weil die Foundation aktiv löscht. Die “ClawHavoc”-Kampagne ist dabei besonders gut dokumentiert: Angreifer publizierten Skills unter legitim klingenden Namen (“calendar-sync”, “file-organizer”, “backup-util”), die im Hintergrund API-Tokens extrahierten und an externe Server sendeten.

Ähnliche Angriffe gab es auch gegen npm, PyPI und den VS Code Extension Marketplace. Das ist also kein OpenClaw-spezifisches Problem. Allerdings macht die Kombination aus hoher Berechtigungsstufe (Agenten haben oft Dateisystem- und Netzwerkzugriff) und niedrigschwelligem Marketplace OpenClaw zu einem attraktiven Ziel.

Enterprise-Risiken: Shadow IT und Token-Management

Für Unternehmen ist die technische Sicherheitslage nur ein Teil des Problems. Der eigentliche Risikofaktor ist die unkontrollierte Adoption.

Ein großes Risiko liegt in der Shadow-IT-Dynamik. OpenClaw lässt sich in Minuten aufsetzen, weshalb Entwickler und Power-User es auf eigenen Rechnern oder privaten VMs installieren, oft ohne Wissen der IT-Abteilung. Die Folge: KI-Agenten mit Zugriff auf Unternehmensressourcen laufen außerhalb jedes Security-Monitorings.

Ein weiteres Problem ist die Token-Speicherung. OpenClaw speichert API-Tokens und Credentials in einer lokalen Konfigurationsdatei ohne Verschlüsselung. In der Standardkonfiguration liegen diese Tokens im Klartext in ~/.openclaw/config.yaml. Wer das Tool mit Unternehmens-APIs verbindet (interne REST-Services, Confluence, Jira), gibt diesen Credentials keinen Schutz.

Compliance und Datenflüsse stellen ein drittes Problem dar. Agenten, die auf Unternehmens-Dateien zugreifen und externe Dienste aufrufen, bewegen sich in einem regulatorischen Graubereich. Welche Daten fließen über welche Verbindungen? Werden DSGVO-relevante Informationen in externe LLM-APIs gesendet? Ohne Policy-Oversight gibt es darauf keine Antwort.

Diese Situation sehen wir auch bei anderen Automatisierungstools immer wieder. Die Lösung liegt nicht im Verbot, sondern in klaren Governance-Strukturen. Ähnlich wie bei der systematischen Behandlung technischer Schulden heißt es auch hier: Problem erst verstehen, dann kontrolliert adressieren.

Fazit: Potenzial ja, aber mit Governance

OpenClaw zeigt, wie groß der Bedarf an selbst gehosteten, autonomen Agenten ist. Die Architektur ist solide, die Community aktiv, und der Ansatz, KI lokal mit echten Ressourcen zu verbinden, löst ein reales Problem.

Allerdings ist die aktuelle Sicherheitslage nicht produktionstauglich, ohne aktiv gegengesteuert zu werden.

Konkrete Empfehlungen zur Risikominderung sind:

Alle fünf CVEs haben Patches, die eingespielt werden müssen. CVE-2026-24763 und CVE-2026-30741 sind kritisch genug, um ungepatchte Instanzen sofort vom Netz zu nehmen.
Jeder externe Skill sollte vor dem Einsatz auf den Quellcode geprüft werden. Automatisierte Dependency-Scans helfen, reichen aber nicht.
Credentials gehören in ein Secrets-Management-System (HashiCorp Vault, AWS Secrets Manager), nicht in eine Plaintext-Config-Datei. Token-Management muss nachgerüstet werden.
Ein Netzwerk-Scan auf OpenClaw-typische Ports (Standard: 8742) gibt Aufschluss darüber, ob das Tool bereits unkontrolliert im Einsatz ist, um Shadow IT aufzuspüren.
Klären Sie vorab: Wer darf OpenClaw einsetzen? Mit welchen Berechtigungen? Welche Daten dürfen durch Agenten fließen? Ein Governance-Framework muss definiert sein, bevor der Rollout startet.

OpenClaw wird sich weiterentwickeln. Die Foundation hat die Sicherheitsprobleme erkannt und arbeitet an strukturellen Fixes. Wer das Tool im Enterprise-Kontext evaluiert, sollte dies als Startpunkt sehen und einen kontrollierten Piloten starten, bevor breite Adoption stattfindet.

Zum Thema gibt es außerdem ein begleitendes Video auf unserem YouTube-Kanal.

Wenn ihr OpenClaw oder vergleichbare Agenten-Frameworks in eurer Organisation evaluiert und dabei Unterstützung bei Architektur, Security-Review oder Governance braucht, sprecht uns an →

Häufige Fragen

Wie kritisch sind die OpenClaw-Schwachstellen wirklich?

CVE-2026-24763 (Remote Command Injection) und CVE-2026-30741 (Prompt Injection) sind kritisch genug, um ungepatchte Instanzen sofort vom Netz zu nehmen. Sicherheitsforscher identifizierten 40.000+ öffentlich erreichbare OpenClaw-Instanzen, 35-63 Prozent laufen ungepatchte Versionen, 12.812 sind anfällig für Remote Code Execution.

Was ist das “ClawHavoc”-Problem?

Zwischen 341 und 824 bösartige Skills wurden im Marketplace hochgeladen. Angreifer publizierten sie unter legitim klingenden Namen wie “calendar-sync” oder “file-organizer”, sie extrahierten im Hintergrund API-Tokens und sendeten sie an externe Server. Das Problem ist nicht OpenClaw-spezifisch, aber die Kombination aus hohen Berechtigungen und niedrigschwelligem Marketplace macht es hier besonders riskant.

Wie lagert OpenClaw Credentials standardmäßig?

Im Klartext in ~/.openclaw/config.yaml, ohne Verschlüsselung. Das ist ein erhebliches Risiko wenn das Tool mit Unternehmens-APIs verbunden ist. Besser: Credentials in ein Secrets-Management-System wie HashiCorp Vault oder AWS Secrets Manager auslagern, nicht lokal speichern.

Was sollten Unternehmen vor OpenClaw-Einsatz klären?

Definieren Sie vorab: Wer darf OpenClaw einsetzen? Mit welchen Berechtigungen? Welche Daten dürfen durch Agenten fließen? Ein Governance-Framework muss stehen, bevor der Rollout startet. Ferner: Netzwerk-Scans auf OpenClaw-typische Ports (Standard: 8742) zur Erkennung von Shadow IT durchführen.