OpenClaw sicher betreiben: Risiken, CVEs, ClawHub-Supply-Chain + Hardening

Stand: 08. Februar 2026 – zuletzt aktualisiert

Autor: Mika Schmidt (IT-Security Consultant) – Six Eight Consulting, Fokus: ISMS, Hardening, Incident Response.

In diesem Guide zeigen wir, wie Unternehmen OpenClaw (ehemals Clawdbot/Moltbot) sicher betreiben. Keine Sorge: OpenClaw wird dir 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 dein 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. [Doku]

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). [News] [News] [Website] [Threat Intel]

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.

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

1. 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.1.29, sofort patchen (mehrere High-Impact-Fixes + Hardening Defaults). [Release]
• Wo liegen Tokens/Secrets? In State-Verzeichnissen, Logs oder Skill-Dateien erhöhen sie den Blast Radius bei Host-Kompromittierung. [Doku]
• Installierst du Skills direkt aus ClawHub? ClawHub scannt inzwischen mit VirusTotal (Code Insight) + tägliche Rescans – das verbessert den Basisschutz. Für Produktion brauchst du trotzdem Allowlist + Review (+ optional z. B. AI Skills Checker als weiteren Filter). [News] [Tool]
• Darf der Agent auf dem Host Commands ausführen? Host-Execution („elevated“) ist die gefährlichste Einstellung – nur für eng definierte Use Cases. [Doku]

Wenn ihr unsicher seid, ob euer Gateway exponiert ist: Ein IT-Security Check (Exposure & Hardening prüfen) bringt schnell Klarheit – ohne Over-Engineering.

2. 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 deinen Sicherheitsrahmen. [Doku]

2.1 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.

2.2 Tool-Policy & Sandbox: Dein „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. [Doku]

2.3 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). [Analyse] [Threat Intel]

3. 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 ist Token-Schutz und kein Public Exposure die Basis.

3.1 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.

• CVE-2026-25253: Token-Exfiltration über manipulierte Verbindung (u. a. via Parameter/Origin-Themen) und anschließende Gateway-Übernahme – bis hin zu RCE. [Advisory]
• CVE-2026-24763: Command Injection im Docker-Sandbox-Mechanismus über unsichere PATH-Behandlung. [Advisory]
• CVE-2026-25157: OS Command Injection in macOS-SSH/Remote-Handling (u. a. durch unescaped Projektpfade / Target-Validierung). [Advisory]

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.

3.2 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. Die wichtigste Regel bleibt daher: Kein Public Exposure. [Doku]

3.3 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. [Analyse] [Analyse]

3.4 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. [News] Für eine praxisnahe Taxonomie hilft OWASP LLM Top 10. [Standard]

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

Diese Tabelle fasst die wichtigsten Angriffspfade und sinnvolle Gegenmaßnahmen zusammen – so, dass du sie direkt als Maßnahmenplan nutzen kannst.

4. Sofortmaßnahmen & Hardening: Was du heute umsetzen kannst

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

Wenn ihr unsicher seid, ob euer Setup ausreicht: Ein IT-Security Check (Exposure & Hardening prüfen) oder Projektbegleitung für Patch-Management & Hardening bringt Struktur.

1. Patchen & Versionen inventarisieren: Behandle OpenClaw wie ein produktives System: Inventar, Wartungsfenster, Regression-Test, schnelle Einspielung kritischer Fixes. [Release]
2. Tokens rotieren & Sessions prüfen: Wenn Token-Exfiltration möglich war, ist Rotation Pflicht. Lege dafür eine „Break-Glass“-Prozedur fest (Rotation, Channel-Disconnect, Skill-Disable). [Doku]
3. Remote-Zugriff sauber lösen: Kein Public Port. Nutze SSH-Tunnel oder Tailnet/VPN und halte Gateway loopback-only. [Doku]
4. Tool-Policy minimieren: Entferne Tools, die du nicht brauchst. Host-Execution ist Ausnahme, nicht Standard. [Doku]
5. Skills kontrollieren: Default-Deny für externe Skills in Produktion. Review-Prozess, Scans, Version-Pinning, interne Registry/Mirror. Optional: automatisierter Erstcheck als Filter (ersetzt keinen Review). [Tool] [Threat Intel]

5. 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. [Doku]

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

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

6.1 Remote-Zugriff per SSH-Tunnel statt Public Exposure

Beispiel: 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.
    

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

Wenn du wirklich einen Reverse Proxy brauchst: starke Auth, kein localhost-Trust, harte Defaults, Logging. Und: erst prüfen, ob nicht SSH/Tailnet besser passt.

Beispiel-Konfiguration: 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;
        }
      }
    

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

Ziel: Tools nur freigeben, wenn du sie wirklich brauchst. 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
    

6.4 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
        }
      }
    

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

8. 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. [Leitfaden]

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).

9. Häufige Fragen aus der Praxis

9.1 Reicht „localhost-only“, um sicher zu sein?

Es ist ein sehr guter Start, aber kein Freifahrtschein. Entscheidend sind Patch-Level, Token-Schutz, sauberes Remote-Modell (SSH/Tailnet), getrennte Browser-Profile und ein minimierter Tool-Surface. [Doku]

9.2 Können wir ClawHub in Produktion nutzen?

Wenn ihr es tut, braucht ihr Supply-Chain-Gates: Default-Deny, Allowlist, Review, Scans und Version-Pinning. „Prerequisites“-Installationsanleitungen aus Skills sind ein High-Risk-Indikator. [Analyse] [Threat Intel]

9.3 Wie gehen wir konkret gegen Prompt Injection vor?

Behandelt externe Inhalte als untrusted, nutzt Approvals für kritische Tools, trennt Input von Instruction, reduziert Tools und überwacht Tool-Aufrufe. OWASP LLM Top 10 hilft als Baseline für Tests. [Standard]

9.4 Was ist die kleinste sinnvolle Sicherheitsbaseline?

Patchen (mind. v2026.1.29), Tokens rotieren, kein Public Exposure, Tool-Policy minimieren, Host-Execution deaktivieren, Skills nur intern/allowlisted – plus Logging/Monitoring. [Release]

9.5 Was kostet OpenClaw absichern / wie hoch ist der Aufwand?

Nicht als Produktpreis, sondern als Aufwand: 1–2 Stunden für einen Quick Fix (Patch, Token-Rotation, Exposure prüfen), etwa 1 Tag für strukturiertes Hardening inkl. Dokumentation. Im Enterprise-Kontext kommt laufender Patch-Prozess, Change Control und ggf. ISMS-Integration dazu – also dauerhafter Aufwand.

9.6 Wie kann ich Skills schnell prüfen, ohne jedes Repo manuell zu reviewen?

Ein pragmatischer Weg ist ein automatisierter Erstcheck als Filter (z. B. Bitdefender AI Skills Checker), um typische Red Flags (verdächtige Installer-Commands, obfuscation, risky patterns) schneller zu sehen. Wichtig: Das ersetzt keinen Freigabeprozess. Für Produktion gilt weiterhin: Default-Deny, Allowlist, Version-Pinning, internes Mirror, und keine Copy-&-Paste-„Prerequisites“ aus Skill-Beschreibungen. [Tool] [Advisory]

9.7 Reicht VirusTotal-Scanning für sichere Skills?

Nein. VirusTotal (bzw. der ClawHub-Security-Gate mit VT Code Insight) hilft gegen Malware und bekannte Schadmuster in Skill-Bundles. Es schützt nicht ausreichend vor Prompt Injection, versteckten Payloads, Verhaltensrisiken oder der Einhaltung Ihrer Tool-Policy – dafür bleiben Review, Default-Deny und Change Control nötig. [News]

9.8 Wie prüfe ich Skills vor Prod-Rollout am schnellsten?

Kombination aus ClawHub/VirusTotal-Scan (automatischer Gate), eigenem Review (Code/Prerequisites prüfen), Version-Pinning und ggf. interner Registry. Der VT-Gate filtert Malware; der Freigabeprozess für Produktion bleibt Allowlist + Pinning + internes Mirror. [Blog]

9.9 Wie oft sollte ich Skills re-validieren?

Bei jedem Skill-Update und regelmäßig im Rahmen Ihrer Change Control. ClawHub führt tägliche Rescans bereits aktiver Skills durch („clean → später malicious“-Szenario). Intern sollten Sie trotzdem einen Re-Validierungsrhythmus und klare Prozesse für Updates haben. [News]