Über 135.000 OpenClaw-Instanzen sind ungeschützt im Internet erreichbar. Eine kritische Schwachstelle ermöglicht Remote-Code-Execution mit nur einem Klick über jeden Browser. Forscher haben über 1.100 bösartige Skills gefunden, die Atomic Stealer über ClawHub verbreiten. Microsoft veröffentlichte einen Blogbeitrag mit dem Titel „Running OpenClaw Safely”, der mit der Feststellung beginnt, dass „für die meisten Umgebungen die angemessene Entscheidung sein könnte, es nicht zu deployen.” Das belgische nationale Cybersicherheitszentrum gab eine behördliche Warnung heraus. Cisco bezeichnete persönliche KI-Agenten wie OpenClaw als „einen Sicherheitsalptraum.”

Das ist keine Panikmache. Das sind Fakten von unabhängigen Sicherheitsforschern, Enterprise-Anbietern und Regierungsbehörden. Wenn Sie eine OpenClaw-Instanz betreiben, betrifft Sie das.

Was schiefgelaufen ist

OpenClaw wurde für localhost entwickelt. Man installiert es auf dem eigenen Rechner, kommuniziert über eine lokale Weboberfläche und lässt es Aufgaben erledigen. Das Sicherheitsmodell ging davon aus, dass die Person, die auf die Oberfläche zugreift, auch die Person ist, die vor dem Computer sitzt.

Dann stieg OpenClaw innerhalb weniger Wochen von 9.000 auf über 200.000 GitHub-Stars. Menschen deployten es auf VPS-Servern, machten es über das Internet zugänglich und verbanden es mit ihren Messaging-Kanälen. Die Localhost-Annahme funktionierte im großen Maßstab nicht mehr. (Wir haben das gesamte Spektrum der Deployment-Optionen und ihre Sicherheits-Kompromisse in einem separaten Leitfaden behandelt.)

CVE-2026-25253: Remote-Code-Execution mit einem Klick

Die schwerwiegendste Schwachstelle ist CVE-2026-25253, bewertet mit CVSS 8.8. OpenClaw validierte keine WebSocket-Origin-Header. So funktioniert der Angriff:

  1. Das Opfer besucht eine bösartige Webseite (oder eine Seite mit bösartiger Werbung).
  2. JavaScript auf dieser Seite öffnet eine WebSocket-Verbindung zu localhost:18789, dem Standard-OpenClaw-Port.
  3. Da sich der Browser auf demselben Rechner befindet, umgeht die Verbindung alle Firewall-Regeln.
  4. Der Angreifer extrahiert das Gateway-Authentifizierungstoken über den WebSocket.
  5. Mit dem Token hat der Angreifer volle Kontrolle: Shell-Zugang, Lese-/Schreibzugriff auf Dateien und Befehlsausführung.

Das Binden an localhost hilft nicht. Der Angriff nutzt den eigenen Browser des Opfers als Sprungbrett. Die Analyse von SOCRadar beschreibt die vollständige Angriffskette.

Bösartige Skills und Supply-Chain-Angriffe

Forscher fanden 341 bösartige Skills auf ClawHub Anfang Februar. Diese Zahl ist seitdem auf über 1.100 gewachsen. Die ClawHavoc-Kampagne verbreitet Atomic Stealer über Skills, die legitim aussehen, aber versteckte Befehlsausführungsschritte enthalten. Skills sind Markdown-Dateien. Eine versteckte Anweisung wie „führe diesen Shell-Befehl aus” lässt sich leicht einbetten und ist schwer zu erkennen.

Am 17. Februar ging der Cline-Supply-Chain-Angriff noch weiter. Ein kompromittiertes npm-Token wurde verwendet, um eine Version der Cline CLI zu veröffentlichen, die stillschweigend OpenClaw auf Entwicklermaschinen installierte. Der Angriff zielte auf die Build-Pipeline selbst ab.

Forscher haben inzwischen sechs weitere Schwachstellen im OpenClaw-Kern offengelegt, darunter CVE-2026-27001. Die OWASP Top 10 für Agentic Applications listet viele dieser Muster mittlerweile als Top-Risiken. Wie Conscias Analyse es formuliert: Dies ist eine ausgewachsene Sicherheitskrise.

Warum ein Gateway-Token nicht ausreicht

Die eingebaute Authentifizierung von OpenClaw ist ein statisches Token. Man setzt es einmal, und jede Anfrage muss es enthalten. Das ist besser als nichts. Aber es hat grundlegende Einschränkungen.

Statische Tokens laufen nicht ab. Wenn ein Token durchsickert (über CVE-2026-25253, über Logs, über einen bösartigen Skill, der Umgebungsvariablen ausliest), hat der Angreifer dauerhaften Zugang, bis Sie es bemerken und manuell rotieren.

Statische Tokens können nicht eingeschränkt werden. Das Gateway-Token gewährt vollen Zugriff. Es gibt keine Möglichkeit, jemandem nur Lesezugriff zu geben oder einzuschränken, was eine authentifizierte Sitzung tun kann.

Statische Tokens können nicht einem Benutzer zugeordnet werden. Wenn drei Personen ein Token teilen, gibt es keinen Audit-Trail darüber, wer was getan hat.

Die meisten VPS-Deployment-Anleitungen empfehlen, OpenClaw hinter nginx mit Basic Auth zu betreiben. Das ist besser, aber immer noch ein statisches Credential. Wenn es jemand abfängt (Network Sniffing über eine unverschlüsselte Verbindung, eine kompromittierte Reverse-Proxy-Konfiguration, eine geleakte .htpasswd-Datei), ist die Person drin.

Das grundlegende Problem liegt tiefer: Die Authentifizierung findet innerhalb der Anwendung statt. Wenn die Anwendung eine Schwachstelle hat, kann die Authentifizierung umgangen werden. CVE-2026-25253 hat genau dies demonstriert. Das Gateway-Token existierte. Die Schwachstelle extrahierte es, bevor die Anwendung überhaupt eine Chance hatte, es zu überprüfen.

Deshalb haben wir OpenClaw.rocks mit Authentifizierung auf Proxy-Ebene entwickelt. Die folgenden Abschnitte erklären die Architektur im Detail. Wenn Sie einfach eine sichere Instanz möchten, ohne das alles selbst aufzubauen, sehen Sie sich unsere Pläne an.

Wie wir das Gateway absichern

Bei OpenClaw.rocks findet die Authentifizierung auf der Proxy-Ebene statt, bevor die Anfrage den OpenClaw-Pod überhaupt erreicht. Dies ist ein struktureller Unterschied, nicht nur ein Konfigurationsunterschied.

Hier ist die dreischichtige Architektur.

Schicht 1: Signierte Gateway-Cookies (HMAC-SHA256)

Wenn Sie über das OpenClaw.rocks-Dashboard auf Ihre OpenClaw-Instanz zugreifen, generiert der Server einen signierten Cookie. Das Format ist:

{expiry}.{userId}.{instanceId}.{hmac_base64url}

Der Cookie hat eine TTL von 4 Stunden und wird alle 45 Minuten automatisch erneuert. Er ist pfadgebunden auf /gw/{instanceId}, sodass ein Cookie nicht für den Zugriff auf eine andere Instanz verwendet werden kann. Er ist HttpOnly (JavaScript kann ihn nicht lesen), Secure (wird nur über HTTPS gesendet) und SameSite=Lax (wird nicht bei Cross-Origin-Anfragen gesendet). Die HMAC-Verifizierung erfolgt mittels zeitkonstantem Vergleich, um Timing-Angriffe zu verhindern.

Selbst wenn jemand den Cookie-Wert abfängt, kann er keinen neuen fälschen, ohne das Signaturgeheimnis zu kennen. Und der Cookie selbst enthält keine Credentials, die direkten Zugriff auf OpenClaw gewähren.

Schicht 2: Traefik ForwardAuth

Jede Anfrage an eine OpenClaw-Instanz durchläuft Traefik, unseren Reverse Proxy. Bevor die Anfrage weitergeleitet wird, ruft Traefik einen Auth-Gate-Endpunkt auf, der den signierten Cookie verifiziert.

Dies ist reine HMAC-Verifizierung. Keine Datenbankabfragen. Keine Netzwerkanfragen an Supabase oder andere Dienste. Die Entscheidung wird in Mikrosekunden getroffen.

Wenn der Cookie ungültig, abgelaufen oder nicht vorhanden ist, wird die Anfrage auf der Proxy-Ebene abgelehnt. Die Anfrage erreicht OpenClaw nie. Das ist der entscheidende Unterschied. In einem typischen Setup muss OpenClaw selbst entscheiden, ob eine Anfrage erlaubt oder abgelehnt wird. Wenn OpenClaw eine Schwachstelle in seiner Authentifizierungslogik hat, kann ein Angreifer durchschlüpfen. In unserem Setup sieht OpenClaw niemals unauthentifizierten Traffic.

Schicht 3: Gateway-Token-Injektion

Jede OpenClaw-Instanz hat ein eingebautes Gateway-Token. Das ist dasselbe Token, das Sie selbst konfigurieren würden, wenn Sie selbst hosten. Der Unterschied liegt darin, wie es zum Pod gelangt.

In einem typischen Self-Hosting-Setup fügen Sie das Token in eine Konfigurationsdatei ein, speichern es vielleicht in einer Umgebungsvariable und hoffen, dass es nie durchsickert. Ihr Browser muss es bei jeder Anfrage mitsenden, was genau der Weg ist, über den CVE-2026-25253 es extrahierte.

In unserem Setup wird ein kryptographisch zufälliges 32-Byte-Token bei der Instanzerstellung generiert und als Kubernetes Secret gespeichert. Traefik injiziert es als Authorization-Header bei jeder weitergeleiteten Anfrage. Der Browser sieht es nie. Es erscheint nie in einer Konfigurationsdatei, die Sie versehentlich committen könnten. Es reist nie über einen WebSocket, den eine bösartige Seite kapern kann. Das Token existiert, aber es lebt vollständig innerhalb des Clusters und bewegt sich nur zwischen Traefik und dem Pod.

Warum diese Architektur CVE-2026-25253 blockiert

Die Angriffskette von CVE-2026-25253 extrahiert das Gateway-Token über WebSocket. Gehen wir durch, was passiert, wenn dieser Angriff auf eine OpenClaw.rocks-Instanz abzielt:

  1. Das JavaScript des Angreifers versucht, einen WebSocket zum OpenClaw-Pod zu öffnen.
  2. Die Verbindung trifft zuerst auf Traefik. Traefik prüft den signierten Cookie.
  3. Die bösartige Seite befindet sich auf einer anderen Origin. Der SameSite=Lax-Cookie wird bei Cross-Origin-WebSocket-Verbindungen nicht gesendet. Die Anfrage wird abgelehnt.
  4. Selbst wenn der Cookie irgendwie angehängt würde, kann die Seite des Angreifers ihn nicht lesen (HttpOnly). Es gibt nichts zu extrahieren.
  5. Selbst wenn der Cookie durchsickern würde, enthält er nicht das Bearer-Token. Das Bearer-Token wird von Traefik injiziert und nie dem Browser offengelegt. Der Angreifer kann es nicht rekonstruieren.

Es gibt nichts zu stehlen, weil der Browser nie die echten Credentials besitzt. Die Angriffsfläche, die CVE-2026-25253 ausnutzt, existiert schlicht nicht.

OpenClaw-Sicherheits-Checkliste für Self-Hoster

Nicht jeder möchte Managed Hosting, und das ist völlig in Ordnung. Wenn Sie Ihre eigene OpenClaw-Instanz betreiben, hier eine praktische Checkliste für 2026.

Ist Ihr Gateway-Auth-Token aktiviert? Führen Sie openclaw doctor aus, um es zu prüfen. Wenn Gateway-Auth deaktiviert ist, kontrolliert jeder, der Port 18789 erreichen kann, Ihren Agenten und alles, worauf er Zugriff hat.

Steht Ihre Instanz hinter einem Reverse Proxy mit TLS? Unverschlüsseltes HTTP bedeutet, dass jeder auf dem Netzwerkpfad Ihr Gateway-Token im Transit lesen kann. Verwenden Sie nginx, Caddy oder Traefik mit einem gültigen TLS-Zertifikat. Let’s Encrypt ist kostenlos.

Verwenden Sie die neueste Version? CVE-2026-25253 wurde in v2026.1.29 gepatcht. CVE-2026-27001 wurde in v2026.2.15 gepatcht. Wenn Sie eine ältere Version verwenden, aktualisieren Sie jetzt. Der Adversa AI Hardening Guide behandelt weitere Schritte.

Haben Sie Ihre installierten Skills geprüft? Die ClawHavoc-Kampagne zielte speziell auf ClawHub. Prüfen Sie jeden Skill, den Sie installiert haben. Wenn Sie ihn nicht selbst installiert haben, entfernen Sie ihn und verifizieren Sie die Quelle.

Validiert Ihr Reverse Proxy WebSocket-Origins? Das ist genau der Vektor, den CVE-2026-25253 ausnutzte. Ihr Reverse Proxy sollte WebSocket-Upgrade-Anfragen von unerwarteten Origins ablehnen. Die Sicherheitsdokumentation von OpenClaw enthält Konfigurationsbeispiele.

Findet Ihre Authentifizierung vor oder nach dem Erreichen von OpenClaw statt? Das ist die Frage, die am meisten zählt. Wenn OpenClaw seine eigene Authentifizierung übernimmt, kann eine Schwachstelle in OpenClaw sie umgehen. Wenn Ihr Reverse Proxy die Authentifizierung übernimmt, erreicht die Anfrage OpenClaw nur, wenn sie bereits verifiziert ist.

Was wir nicht lösen

Ehrlichkeit ist hier wichtig. Proxy-Level-Authentifizierung löst die Gateway-Sicherheit. Sie löst nicht alles.

Prompt Injection ist ein Problem auf Anwendungsebene. Eine geschickt formulierte Nachricht kann den Agenten potenziell dazu bringen, unbeabsichtigte Aktionen auszuführen. Dies ist ein aktives Forschungsgebiet in der gesamten KI-Branche, und kein Hosting-Anbieter kann es heute vollständig verhindern.

Bösartiges Skill-Verhalten findet innerhalb des Kontexts des Agenten statt. Wenn Sie einen Skill installieren, der Daten über erlaubten HTTPS-Egress exfiltriert, kann Proxy-Auth das nicht aufhalten. Was unsere Infrastruktur leistet, ist den Schadensradius einzugrenzen: Jede Instanz läuft in ihrem eigenen Kubernetes-Pod mit Netzwerkisolierung, reduzierten Capabilities, seccomp und einem schreibgeschützten Root-Dateisystem. Ein kompromittierter Agent kann keine anderen Agenten oder das Host-System erreichen. Der Kubernetes-Operator erzwingt diese Standardeinstellungen für jede Instanz.

LLM-Provider-Vertrauen hängt von Ihrem Plan ab. Wenn Sie Ihre eigenen API-Keys verwenden (Light-Plan), laufen Ihre Gespräche über den Provider, den Sie konfigurieren, und dessen Datenschutzrichtlinie gilt. Beim Pro-Plan leiten wir den Traffic über unser eigenes AI-Gateway mit vorkonfigurierten Providern. Sie müssen Ihre API-Keys keiner OpenClaw-Instanz anvertrauen oder darauf vertrauen, dass ein Drittanbieter-Key sicher gespeichert wird. Das Gateway verwaltet die Provider-Credentials in Ihrem Auftrag, und Sie sehen oder handhaben sie nie direkt.

Sicherheit besteht aus Schichten. Wir kümmern uns um die Infrastruktur-Schichten. Die Herausforderungen auf Anwendungsebene sind real und es lohnt sich, sie zu verstehen.

Sicherheit ist eine Architekturentscheidung

Die OpenClaw-Sicherheitskrise dreht sich nicht um einen einzelnen CVE oder eine einzelne Charge bösartiger Skills. Es geht um ein Tool, das für localhost entwickelt wurde und von Hunderttausenden Menschen im Internet deployed wird, mit Authentifizierung, die innerhalb der Anwendung stattfindet, die sie eigentlich schützen soll.

Die Authentifizierung auf die Proxy-Ebene zu verlagern, ist kein Feature. Es ist eine Architekturentscheidung. Sie bedeutet, dass wenn der nächste OpenClaw-CVE veröffentlicht wird (und das wird passieren), authentifizierte Anfragen immer noch verifiziert werden, bevor sie die Anwendung berühren. Die Angriffsfläche ist strukturell kleiner.

Wir haben diese Entscheidung am ersten Tag getroffen. Jede OpenClaw.rocks-Instanz läuft hinter signierten Cookies, ForwardAuth-Verifizierung und instanzspezifischen Bearer-Tokens. Keine Gateway-Tokens im Browser. Keine statischen Credentials zum Extrahieren. Keine Authentifizierungslogik innerhalb der verwundbaren Anwendung.

Wenn Sie mehr darüber lesen möchten, wie wir OpenClaw auf Kubernetes mit vollständiger Sicherheitshärtung deployen, behandelt der Deployment-Leitfaden dies im Detail.

Wenn Sie einfach einen laufenden Agenten möchten, der sicher bleibt, ohne über all das nachdenken zu müssen, genau dafür haben wir das gebaut.

Starten Sie auf OpenClaw.rocks oder erkunden Sie den Open-Source Kubernetes-Operator, wenn Sie Ihre eigene Infrastruktur betreiben möchten.