OpenClaw sicher betreiben: Hardening & Supply-Chain-Risiken

In diesem Guide zeigen wir, wie Unternehmen OpenClaw (ehemals Clawdbot/Moltbot) sicher betreiben. Keine Sorge: OpenClaw wird Ihnen morgen früh nicht mit rotem Leuchten in den Augen den Laptop entreißen und „ACCESS GRANTED“ brüllen.

Was allerdings realistisch ist: Ein falsch abgesicherter KI-Agent mit Zugriff auf Systeme, Tokens und Tools kann unbemerkt genau das tun, was auf dem Hero Image dramatisch dargestellt ist – nur leiser, schneller und deutlich unbequemer für Ihr Unternehmen.

OpenClaw ist kein „Chatbot-Tool“, sondern ein agentischer Orchestrator: Er verbindet LLMs mit Tools (z. B. Kommandoausführung, Browser-Steuerung, API-Calls) und kann Aufgaben nicht nur beantworten, sondern ausführen. Genau das macht ihn im Unternehmen spannend – und sicherheitlich heikel.

Ein zusätzlicher Punkt, den viele unterschätzen: Das Ökosystem ist noch extrem jung – und fühlt sich stellenweise nach „immature code“ an. Heißt: schnelle Feature-Iterationen, wenig Produktionsreife und eine Security-Realität, in der nicht jeder Pfad lange getestet oder hart abgesichert ist. Ein Indikator dafür ist auch die Außenwirkung: In kurzer Zeit gab es gleich zwei öffentliche Rebrandings – Clawdbot → Moltbot → OpenClaw (der aktuelle Produktname). Genau solche Phasen erzeugen nicht nur technische Kinderkrankheiten, sondern auch Angriffsfläche durch Verwirrung (z. B. Fake-Repos, Typosquatting, Impersonation-Kampagnen).

Im gleichen Ökosystem zeigt das Agenten-Netzwerk Moltbook vergleichbare Risiken (Datenleck, Reverse Prompt Injection, API-Keys). Dazu haben wir einen eigenen Praxis-Guide geschrieben: Moltbook: Autonomie von KI-Agenten, Selbstregulierung & Angriffe auf API-Keys.

Update Mai 2026: Für die neu veröffentlichten Claw-Chain-Schwachstellen gibt es eine separate deutschsprachige Einordnung mit CVE-Übersicht, Patch-Hinweisen und Incident-Response-Checkliste (Claw Chain: OpenClaw-Schwachstellen bei AI-Agenten absichern).

In diesem Beitrag erhalten Sie eine pragmatische Antwort auf drei Fragen: Bin ich betroffen? Welche aktuellen Risiken sind relevant? Und wie können Sie OpenClaw so sicher wie möglich betreiben – ohne Over-Engineering.

Bin ich betroffen? Schnellcheck für Unternehmen

Der größte Hebel ist nicht „KI-Sicherheit“ im Abstrakten, sondern ganz konkret: Exposure, Tokens, Skills und Tool-Rechte. Nutze diese Fragen als schnellen Reality-Check:

• Ist Control UI oder Gateway aus dem Internet erreichbar? Wenn ja: als kritisch behandeln (insbesondere bei Reverse-Proxies ohne starke Auth).
• Welche Version läuft produktiv? Wenn < v2026.2.15, sofort patchen (u. a. viele Security-Fixes in 2026.2.14/2026.2.15; besser: aktuell 2026.3.11).
• Wo liegen Tokens/Secrets? In State-Verzeichnissen, Logs oder Skill-Dateien erhöhen sie den Blast Radius bei Host-Kompromittierung.
• Installieren Sie Skills direkt aus ClawHub? ClawHub scannt inzwischen mit VirusTotal (Code Insight) + tägliche Rescans – das verbessert den Basisschutz. Für Produktion brauchen Sie trotzdem Allowlist + Review (+ optional z. B. AI Skills Checker als weiteren Filter).
• Darf der Agent auf dem Host Commands ausführen? Host-Execution („elevated“) ist die gefährlichste Einstellung – nur für eng definierte Use Cases.
• Cline CLI (npm) genutzt? Wenn Sie zwischen 17.02.2026 ca. 12:26 und 19:30 UTC cline@2.3.0 installiert oder aktualisiert haben, wurde dabei ggf. OpenClaw global installiert. Prüfen Sie mit npm list -g openclaw und deinstallieren Sie bei unerwünschter Installation; Cline auf 2.4.0+ aktualisieren.

Grundlagen: Was OpenClaw technisch ist – und warum das wichtig ist

OpenClaw ist kein KI-Modell, sondern ein Agent-Orchestrator. Typisch ist ein Setup mit: Gateway/Daemon, Control UI, Tool-Policy, Sandbox/Elevated-Modus, Skills/Extensions und persistentem Zustand (Sessions, Logs, Memory). Genau diese Bausteine definieren Ihren Sicherheitsrahmen.

Agentic AI: „Antworten“ vs. „Ausführen“

Klassische Chatbots liefern Text. Agenten führen Aktionen aus: API-Calls, Browser-Automation, Kommandos, Ticket-Erstellung. Damit ähneln sie eher einem Automation-Controller als einem Tool fürs Marketing-Team. Wer OpenClaw einführt, muss ihn wie ein privilegiertes System behandeln.

Tool-Policy & Sandbox: Ihr „Blast Radius“-Regler

OpenClaw unterscheidet (a) welche Tools ein Agent nutzen darf (Tool-Policy) und (b) wo diese Tools laufen (Sandbox vs. Host). Ein erlaubtes Tool im falschen Modus kann den Blast Radius massiv erhöhen.

Skills sind Code – und damit Supply-Chain

Skills werden wie Bundles installiert (häufig ZIP/Repo-basiert) und können zusätzliche Skripte/Tools enthalten. In freier Wildbahn wurde genau das als Angriffsfläche genutzt: bösartige Skills, die über „Prerequisites“ zur Malware-Installation führen (z. B. Infostealer-Kampagnen).

Aktuelle Risiken & Angriffspfade: Was derzeit wirklich passiert

Die Risikolage lässt sich in zwei Ebenen teilen: (A) klassische IT-Security-Risiken (Exposure, Token-Diebstahl, Command-Injection, Supply-Chain) und (B) agentenspezifische Risiken (Prompt Injection, Memory Poisoning, Tool Misuse).

Entscheidend: Sobald der Token weg ist, helfen Approvals oft nicht mehr – deshalb sind Token-Schutz und kein Public Exposure die Basis.

Kritische Schwachstellen (CVE/Advisories) – warum Patch-Level ein Security-Gate ist

Besonders relevant waren in kurzer Zeit mehrere High-Impact-Issues, weil sie direkt in die „Agent-Macht“ greifen: Token → Gateway-Kontrolle → Tool-Policy/Sandbox → Host-Execution. Der Security-Fix-Takt ist hoch: In 2026.2.15 wurden über 60 Schwachstellen gebündelt behoben (laut heise/CERT Bund teils kritisch bis CVSS 10) – ein klares Argument, warum Patch-Management für OpenClaw ein Pflichtprozess ist. Seit Mai 2026 kommt mit Claw Chain eine weitere Schwachstellenkette hinzu (CVE-2026-44112, CVE-2026-44113, CVE-2026-44115 und CVE-2026-44118; eigener Beitrag). Viele Fixes (u. a. CVE-2026-26320) sind bereits in 2026.2.14 bzw. 2026.2.15 adressiert; Mindestbaseline daher 2026.2.15+, besser aktuell 2026.3.11. In 2026.3.11 wurde zudem WebSocket-Origin-Validierung (GHSA-5wcw-8jjv-m286) nachgezogen; ab 2026.3.7 ist gateway.auth.mode Pflicht, wenn sowohl Token als auch Passwort (inkl. SecretRefs) gesetzt sind.

• CVE-2026-25253: Token-Exfiltration über manipulierte Verbindung (u. a. via Parameter/Origin-Themen) und anschließende Gateway-Übernahme – bis hin zu RCE.
• CVE-2026-24763: Command Injection im Docker-Sandbox-Mechanismus über unsichere PATH-Behandlung.
• CVE-2026-25157: OS Command Injection in macOS-SSH/Remote-Handling (u. a. durch unescaped Projektpfade / Target-Validierung).
• GHSA-5wcw-8jjv-m286: WebSocket Cross-Origin-Hijacking im trusted-proxy-Modus – ohne strikte Browser-Origin-Prüfung konnten unerwünschte Origins operator.admin erhalten. Fix in 2026.3.11.
• CVE-2026-26324: SSRF-Bypass vor 2026.2.14 durch IPv4-mapped-IPv6-Adressen (::ffff:127.0.0.1 & Co.). Relevant für alle Setups, die sich auf Host-Allow-/Deny-Regeln oder lokale-only Annahmen verlassen.
• CVE-2026-26326: skills.status konnte vor 2026.2.14 aufgelöste Konfigurationswerte in configChecks an operator.read-Clients leaken. Praxisfolgen: potenzieller Secret-Abfluss, insbesondere bei Skill-Tokens; nach Update ggf. betroffene Tokens rotieren.
• CVE-2026-27001: Unsanitized Workspace-Pfade konnten vor 2026.2.15 in den System-Prompt injizieren, wenn ein Projektordner gezielt mit Steuerzeichen, Zeilenumbrüchen oder Unicode-Formatzeichen benannt wurde. Besonders relevant in Entwickler-Workflows mit fremden Repositories.
• CVE-2026-27004: In Shared-Agent-/Multi-User-Szenarien konnten vor 2026.2.15 Tool-Ergebnisse oder Kontext zwischen Sessions ungewollt wirksam werden. Argument, Agenten nicht mandantenübergreifend zu teilen und Sitzungen sauber zu trennen.
• CVE-2026-28470: Command Injection in der Exec-Approvals-Allowlist (unerwünschte Command-Substitution in doppelten Anführungszeichen). Fix in 2026.2.2; betroffen nur bei aktivierten Exec-Approvals.

Wichtig für die Praxis: Sicherheitsfeatures wie Approvals und Sandbox helfen – aber sobald ein hochprivilegierter Token kompromittiert ist, können Angreifer Konfigurationen über die API manipulieren. Deshalb ist Token-Schutz fundamental, nicht optional.

Exponierte Instanzen: „Quick Reverse Proxy“ ist der häufigste Totalschaden

Mehrere Berichte zeigen, dass Control Panels/Gateways falsch konfiguriert oder direkt erreichbar waren. Der Impact reicht von Chat-History- und Konfig-Leaks bis zur Agent-Übernahme mit möglicher Command-Ausführung. Exponierte Instanzen wurden zudem für Scraping-Botnetze missbraucht (u. a. Reise- und Retail-Seiten). Die wichtigste Regel bleibt daher: Kein Public Exposure.

Cline CLI Supply-Chain-Angriff (Feb 2026): OpenClaw als Payload

Am 17.02.2026 veröffentlichte eine unbefugte Partei über einen kompromittierten npm-Publish-Token die Version cline@2.3.0 (Cline CLI – ein beliebter KI-Coding-Agent). Das Paket enthielt ein modifiziertes package.json mit einem postinstall-Skript: "postinstall": "npm install -g openclaw@latest". Jede Installation von Cline 2.3.0 installierte damit ungewollt OpenClaw global auf dem System. Das betroffene Fenster lag bei etwa acht Stunden (ca. 12:26–19:30 UTC); StepSecurity beziffert die Downloads auf rund 4.000.

OpenClaw selbst ist in diesem Vorfall nicht bösartig – die Maintainer betonen, dass keine weiteren Änderungen am Paket vorgenommen wurden und kein bösartiges Verhalten beobachtet wurde. Endor Labs stuft den Gesamtimpact als „low“ ein (OpenClaw ist nicht malicious, die Installation startet das Gateway nicht automatisch); für Betroffene gilt dennoch: Unerwünschte OpenClaw-Installation prüfen und bei Bedarf entfernen (npm uninstall -g openclaw), Cline auf 2.4.0+ aktualisieren und ggf. Credentials rotieren.

Ursache: „Clinejection“. Der Angriff wurde durch eine zuvor von Adnan Khan öffentlich dokumentierte Schwachstellenkette ermöglicht: Cline setzte einen KI-gestützten Issue-Triage-Workflow ein (Claude mit Zugriff auf Bash, Read, Write, Edit etc.). Über indirekte Prompt Injection im GitHub-Issue-Titel konnte ein Angreifer Claude dazu bringen, beliebigen Code auszuführen. In Kombination mit GitHub-Actions-Cache-Poisoning (z. B. mit dem Tool Cacheract) ließen sich Cache-Keys des Nightly-Release-Workflows vergiften; beim nächsten Lauf wurden dann die Publish-Tokens (u. a. NPM_RELEASE_TOKEN) ausgelesen. Ein noch aktiver npm-Token (bei der ersten Rotation nicht korrekt widerrufen) wurde genutzt, um cline@2.3.0 zu publizieren.

Der Vorfall wurde breit berichtet (u. a. The Verge, Dark Reading – Enterprise-Kontext). Wichtig: Das VS-Code-/JetBrains-Plugin von Cline war nicht betroffen; nur die CLI (npm cline) war kompromittiert – laut Maintainer-Kommunikation in der Berichterstattung.

Takeaway für OpenClaw-Betreiber: Der Vorfall unterstreicht, dass KI-Agenten in CI/CD und Issue-Triage als privilegierte Akteure behandelt werden müssen (minimale Tools, kein Cache in Release-Pipelines, keine ungefilterte Interpolation von User-Input in Prompts). Für Nutzer von OpenClaw: Unerwartete Installationen können auch über Drittsysteme wie Cline hereinkommen – deshalb Umgebung prüfen und nur gewollte Instanzen betreiben.

Fake-OpenClaw-Installer auf GitHub

Neben der Cline-Supply-Chain kursieren trojanisierte GitHub-Repositories, die sich als OpenClaw-Installer ausgeben und stattdessen Infostealer (z. B. Atomic, Vidar) oder Proxy-Malware (GhostSocks) ausliefern. Huntress und andere berichten, dass solche Repos gezielt gepusht wurden und teils als Top-Treffer in Bing-AI-Suchergebnissen für „OpenClaw Windows“ erschienen – Nutzer installieren also vermeintlich OpenClaw und bekommen Malware. Installation nur von offizieller Quelle (openclaw.ai / dokumentierte Installationswege), keine Copy-&-Paste-Commands aus unbekannten Repos oder Foren.

ClawHub & Skills: Supply-Chain-Angriffe ohne Exploit

Der derzeitige Hot-Spot ist die Skill-Supply-Chain: Es wurden Kampagnen mit hunderten bösartigen Skills identifiziert, häufig über Social Engineering („Prerequisites“, Paste-Commands, Passwörter für Archives). Das ist besonders gefährlich, weil Skills typischerweise Zugriff auf Dateien, Browser-Profile, Tokens und Netzwerk haben.

Prompt Injection & Memory Poisoning: Wenn untrusted Input Handlungen triggert

Agentische Systeme konsumieren häufig untrusted Content (E-Mails, Webseiten, Chats) – und können danach handeln. Damit werden Prompt-Injection-Varianten (direkt/indirekt) und Memory Poisoning relevanter als bei reinen Chatbots. Wichtig: Marketplace-Scanning (z. B. VirusTotal in ClawHub) reduziert das Malware-Risiko in Skill-Bundles, nicht die agentische Manipulation. OpenClaw weist selbst darauf hin, dass clever versteckte Prompt-Injection-Payloads durch Scans rutschen können. Behandelt also weiterhin „Input ≠ Instruction“ und haltet Approvals sowie minimierte Tool-Policy aufrecht. Für eine praxisnahe Taxonomie hilft OWASP LLM Top 10.

Indirekte Prompt Injection via Link-Vorschau (IDPI): Forscher (u. a. PromptArmor) haben gezeigt, dass in Messenger mit Link-Vorschau (z. B. Telegram, Discord) ein Angreifer den Agenten dazu bringen kann, eine URL zu erzeugen, die beim Abruf der Vorschau durch die App vertrauliche Daten an eine Angreifer-Domain sendet – ohne dass der Nutzer auf den Link klickt. Data Exfiltration erfolgt damit bereits mit der Agent-Antwort. CNCERT (China) und The Hacker News weisen auf diese und weitere „inherently weak default security configurations“ bei OpenClaw hin. Praxis: Externe Inhalte und Chat-Kontext weiterhin als untrusted behandeln; wo möglich Link-Preview/automatischen Abruf begrenzen oder in isolierten Umgebungen betreiben.

Approval-Spoofing / UI-Täuschung (CVE-2026-26320)

Bestätigungsdialoge (Approvals) sind kein Allheilmittel, wenn die UI den angezeigten Inhalt von der tatsächlich ausgeführten Aktion entkoppeln kann. CVE-2026-26320 betrifft den OpenClaw-macOS-Client: Der Bestätigungsdialog für openclaw://-Deep-Links zeigte nur die ersten 240 Zeichen der Nachricht, führte nach Klick auf „Bestätigen“ aber die vollständige Nachricht aus. Angreifer konnten per Padding (z. B. Leerzeichen) bösartige Payloads aus dem sichtbaren Bereich schieben – Nutzer bestätigten damit etwas anderes als das, was ausgeführt wurde („social-engineering mediated“). Fix in 2026.2.14.

Praxis: Policy-Minimierung (weniger Tools = weniger Angriffsfläche), Logging von Approval-Events und „unexpected prompts while browsing“ als Red Flag – unerwartete „Run OpenClaw agent?“-Dialoge von unbekannten Seiten nicht bestätigen. Unattended Deep Links nur mit gültigen Keys für vertrauenswürdige Automatisierungen nutzen.

Überblick: Risiken, Business-Impact und Gegenmaßnahmen

Diese Tabelle fasst die wichtigsten Angriffspfade und sinnvolle Gegenmaßnahmen zusammen – so, dass Sie sie direkt als Maßnahmenplan nutzen können.

Sofortmaßnahmen & Hardening: Was Sie heute umsetzen können

Wenn Sie OpenClaw produktiv nutzen (oder es planen), sind das die Maßnahmen mit dem besten Aufwand/Nutzen-Verhältnis.

Sicherer Betrieb im Unternehmen: Zielarchitektur „so sicher wie möglich“

Ein realistisches Ziel ist nicht „risikofrei“, sondern kontrolliert, isoliert und auditierbar. Für viele Unternehmen funktioniert OpenClaw am besten als dedizierter Agent-Host – ähnlich einem Jump Host oder Automation-Controller.

Für Remote-Modelle ist ein Tailnet-Ansatz (z. B. Tailscale) attraktiv, weil er Public Ports vermeidet und Identität sauberer modelliert.

Konfig-Beispiele & Checklisten (copy-paste-freundlich)

Die Beispiele sind bewusst klein und praxisnah. Passen Sie sie an Ihre Umgebung an (z. B. Pfade, User, Deployment). Wichtig: Vermeide „Prerequisites“-Pastes aus dem Internet für Skills – genau das wurde in Kampagnen missbraucht.

Remote-Zugriff per SSH-Tunnel statt Public Exposure

Gateway bleibt lokal (loopback), Zugriff nur über SSH-Portforwarding.

# Lokales Portforwarding (Beispiel)
# Lokal: http://localhost:18789 → Remote: 127.0.0.1:18789
ssh -N -L 18789:127.0.0.1:18789 youruser@agent-host.example.internal

# Tipp: Nur aus vertrauenswürdigen Netzen/VPN nutzen.
# Keine Public Reverse-Proxy-„Quick Fixes“ für Control UIs.

Reverse Proxy (nur wenn zwingend nötig) – Mindestanforderungen

Wenn Sie wirklich einen Reverse Proxy brauchen: starke Auth, kein localhost-Trust, harte Defaults, Logging. Und: erst prüfen, ob nicht SSH/Tailnet besser passt. Beispiel: Nginx mit Basic Auth (Minimalbeispiel – in Produktion besser SSO/MFA).

server {
  listen 443 ssl;
  server_name openclaw.internal.example;

  # Auth (Minimal) – in Produktion besser SSO + MFA
  auth_basic "Restricted";
  auth_basic_user_file /etc/nginx/.htpasswd;

  location / {
    proxy_pass http://127.0.0.1:18789;
    proxy_http_version 1.1;

    # Wichtig: WebSocket Support (falls nötig)
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";

    # Kein blindes Trusting von Host/Origin
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-For $remote_addr;
  }
}

Tool-Policy „Least Authority“ – Beispiel als Policy-Skelett

Ziel: Tools nur freigeben, wenn Sie sie wirklich brauchen. Host-Execution ist Ausnahme.

# Pseudo-Beispiel: Tool-Policy Prinzipien (an OpenClaw-Konzept angelehnt)
tools:
  # Default deny – nur explizit erlauben, was nötig ist
  allow:
    - "http.request"      # falls wirklich erforderlich
    - "ticket.create"     # z. B. internes System
    - "calendar.read"     # nur read, nicht write
  deny:
    - "system.run"        # Host-Commands standardmäßig verboten
    - "filesystem.write"  # Schreibzugriff nur, wenn zwingend

execution:
  mode: "sandbox"         # Default: sandbox
  hostExecution:
    enabled: false        # Host-Execution nur als Ausnahme, per Change Control

Skills sicher betreiben: Allowlist + Version-Pinning

Für produktive Umgebungen ist der pragmatische Ansatz: Nur geprüfte Skills, bevorzugt intern versioniert (Mirror/Registry) und mit Pinning auf bekannte Good-Versionen. Beispiel: Interne Allowlist als simple JSON (als Prozess-Artefakt – nicht als „Security by JSON“).

{
  "allowedSkills": [
    { "name": "internal-ticket-skill", "version": "1.4.2", "source": "git@github.com:yourorg/internal-ticket-skill.git" },
    { "name": "internal-knowledge-skill", "version": "2.1.0", "source": "git@github.com:yourorg/internal-knowledge-skill.git" }
  ],
  "policy": {
    "noExternalMarketplaceInProd": true,
    "noPrerequisitePasteCommands": true,
    "reviewRequired": true
  }
}

Lessons Learned: Was Unternehmen aus der OpenClaw-Welle mitnehmen sollten

Recht & Compliance: DSGVO, AI Act, NIS2 (kurz & praxisnah)

Wenn OpenClaw Chats, E-Mails, Kalender oder Dateien verarbeitet, entsteht schnell Personenbezug. Dann gilt: Datenflüsse dokumentieren (inkl. Logs/Memory), TOMs umsetzen und bei hohem Risiko eine DSFA prüfen.

Für NIS2-betroffene Unternehmen gehört der Agent als Asset ins ISMS: Inventar, Risikobewertung, Monitoring, Incident Response und Change Control. Und beim AI Act ist die Einordnung use-case-abhängig (z. B. Transparenz).

Behördliche Warnungen: China warnte offiziell (05.02.2026) vor OpenClaw-Risiken bei unsachgemäßer Konfiguration und empfahl u. a. Identity Verification, Access Controls und Security Audits. Mitte März 2026 verschärften Behörden die Linie: Laut Reuters/Bloomberg wurden staatliche Unternehmen, Behörden und teils Angehörige von Militärpersonal angewiesen, OpenClaw auf Dienstgeräten bzw. in sensiblen Kontexten nicht zu nutzen bzw. vor Nutzung zu prüfen. Zuvor hatte Chinas CERT (CNCERT) in einem WeChat-Post auf schwache Standardkonfigurationen, Prompt-Injection-Risiken (u. a. IDPI/Data Exfiltration) und die Gefahr versehentlicher Löschungen durch Fehlinterpretation von Anweisungen hingewiesen sowie empfohlen, automatische Skill-Updates zu deaktivieren und Skills nur aus vertrauenswürdigen Quellen zu beziehen. Solche Meldungen unterstreichen den Real-World-Impact und die Notwendigkeit von Access Controls, Audits und klaren Vertrauensgrenzen – unabhängig von der Region.

Häufige Fragen aus der Praxis