ClawJacked: Kritische Sicherheitsluecke in OpenClaw gefaehrdet self-hosted KI-Assistenten

CyberSecureFox 🦊

Im self-hosted KI-Umfeld ist eine schwerwiegende Schwachstelle aufgedeckt worden: Die von Oasis Security entdeckte ClawJacked-Sicherheitslücke in OpenClaw ermoeglichte es Angreifern, ueber einen Browser-Tab eine lokale OpenClaw-Instanz zu übernehmen, Administrator-Passwoerter per Brute-Force zu knacken und anschliessend die angebundenen Systeme vollstaendig zu kompromittieren. Die Sicherheitsluecke wurde in der Version 2026.2.26 geschlossen, die am 26. Februar veroeffentlicht wurde.

OpenClaw als zentraler Angriffsvektor in KI-getriebener Automatisierung

OpenClaw ist ein self-hosted Open-Source-KI-Assistent, der autonome Agenten befähigt, Nachrichten zu versenden, Kommandos auszufuehren und Aufgaben quer ueber verschiedene Plattformen zu orchestrieren. Seit dem Start im November 2025 hat das Projekt im Entwickler- und Automatisierungsumfeld rasant an Bedeutung gewonnen und verzeichnet inzwischen ueber 240.000 GitHub-Sterne.

In typischen Setups erhaelt OpenClaw weitreichende Zugriffsrechte: API-Schluessel, Zugangsdaten zu Cloud-Diensten, Zugriff auf CI/CD-Pipelines, Chat- und Kollaborationsplattformen sowie direkte Shell-Zugaenge auf Servern und Workstations. Damit gilt in der Praxis: Wer OpenClaw kontrolliert, kontrolliert weite Teile der umgebenden Infrastruktur. Genau deshalb ist die nun bekannt gewordene ClawJacked-Schwachstelle besonders sicherheitsrelevant.

Technische Analyse: Wie ClawJacked OpenClaw ueber localhost angreifbar machte

WebSocket-Zugriff auf localhost als Einfallstor

Kernkomponente der Architektur von OpenClaw ist ein Gateway-Service, der standardmaessig auf localhost (127.0.0.1) lauscht und eine WebSocket-Schnittstelle bereitstellt. Dieses Design soll den Dienst zunaechst nur lokal zugaenglich machen und so vor direkten Netzwerkangriffen schuetzen.

Die Browser-Sicherheitsarchitektur setzt jedoch an anderer Stelle an: Die Same-Origin-Policy, die Cross-Site-Request-Forgery und andere Webangriffe begrenzen soll, blockiert WebSocket-Verbindungen zu localhost nicht grundsaetzlich. Ein im Browser geoeffneter Tab darf via JavaScript versuchen, ein ws://127.0.0.1:Port-Socket aufzubauen, sofern Port und Protokoll korrekt geraten werden. Aehnliche Angriffsklassen sind aus der Forschung zu DNS-Rebinding und lokalen Service-Angriffen seit Jahren bekannt.

Brute-Force ueber Loopback ohne Rate Limiting

OpenClaw implementierte zwar Schutzmechanismen gegen Brute-Force-Angriffe, doch der Loopback-Adressbereich 127.0.0.1 war explizit von diesen Limits ausgenommen, um lokale CLI-Sessions von Entwicklern und Administratoren nicht zu behindern. Diese Komfortentscheidung wurde zum zentralen Angriffsvektor von ClawJacked.

Ein boesartiger Webauftritt konnte im Browser des Nutzers JavaScript ausfuehren, wiederholt WebSocket-Verbindungen zum lokalen OpenClaw-Gateway herstellen und den Administrator-Login mit Hunderten Passwortversuchen pro Sekunde attackieren – ohne Captcha, ohne Throttling, ohne aussagekraeftige Logeintraege. In der Praxis reicht dies, um gängige Passwortlisten in Sekundenbruchteilen und umfangreichere Wortlisten in wenigen Minuten durchzuspielen.

Fuer menschlich gewaehlt Passwoerter mittlerer Komplexitaet, insbesondere wenn sie aus frueheren Datenlecks bekannt sind, bedeutet dieses Szenario faktisch: Gegen einen derart schnellen Offline-aehnlichen Brute-Force auf dem lokalen Gateway bestehen kaum Chancen.

Vom Passwort-Diebstahl zur vollstaendigen Systemkompromittierung

Nach erfolgreichem Erraten des Administrator-Passworts konnte der Angreifer sein eigenes Geraet als vertrauenswuerdigen Client registrieren. Erschwerend kam hinzu, dass OpenClaw-Gateways Verbindungen von localhost standardmaessig automatisch als vertraut einstufen und das Pairing ohne zusaetzliche Bestaetigung akzeptierten. Dies erleichterte Seitenwechsel von initialem Zugriff hin zu dauerhaftem Administrationszugang.

Mit Administratorrechten erhaelt ein Angreifer umfassende Kontrolle ueber OpenClaw: Einsicht und Exfiltration von Zugangsdaten und Secrets, Uebersicht ueber angebundene Hosts, Zugriff auf Logs, Aufgabenhistorien und Konversationen. Zudem laesst sich der KI-Agent so instruieren, gezielt vertrauliche Informationen in Dialogen zu suchen, Dateien von angebundenen Systemen anzufordern und beliebige Shell-Kommandos auf verbundenen Hosts auszufuehren.

ClawJacked fuehrt damit im schlimmsten Fall zu einer vollstaendigen Kompromittierung der Arbeitsstation und, in Unternehmensumgebungen, grosser Teile der dahinterliegenden Infrastruktur – ausgelöst allein durch das Aufrufen einer praepareirten Website. Vergleichbare Angriffsszenarien auf lokal laufende Entwicklungs- oder Datenbankdienste wurden in der Vergangenheit wiederholt erfolgreich demonstriert, was die Realitaetsnaehe der von Oasis Security veroeffentlichten Proof-of-Concept-Attacke unterstreicht.

Patch 2026.2.26: Reaktion des OpenClaw-Teams

Oasis Security meldete die ClawJacked-Schwaeche im Rahmen eines verantwortungsvollen Disclosure-Prozesses an das OpenClaw-Projekt und lieferte eine detaillierte technische Analyse samt Proof-of-Concept-Code. Das Entwicklerteam reagierte schnell: Innerhalb von weniger als 24 Stunden stand ein Patch in Form des Releases 2026.2.26 zur Verfuegung.

Dem Changelog zufolge wurden die Sicherheitspruefungen fuer WebSocket-Verbindungen deutlich verschaerft und zusaetzliche Schutzmechanismen gegen Missbrauch von Loopback-Verbindungen eingefuehrt. Insbesondere wurde die Authentifizierung lokaler Verbindungen gehärtet, und die Login-Versuchslimits greifen nun explizit auch fuer Anfragen von 127.0.0.1. Damit wird der bisherige Sonderstatus von localhost gezielt reduziert.

Empfehlungen zur Absicherung self-hosted KI-Assistenten

Betroffenen Anwendern ist dringend anzuraten, OpenClaw umgehend auf Version 2026.2.26 oder hoeher zu aktualisieren, insbesondere in produktiven oder Unternehmensumgebungen mit sensiblen Daten und weitreichenden Berechtigungen.

Darueber hinaus sollten grundlegende Härtungsmaßnahmen umgesetzt werden: Der Administrator-Account sollte ein langes, einzigartiges Passwort bzw. eine Passphrase verwenden, die nicht in bekannten Passwortleaks vorkommt. Wo moeglich, sollte der Zugriff auf das OpenClaw-Gateway durch Firewall-Regeln, dedizierte Browser-Profile oder separate Admin-Workstations zusaetzlich begrenzt werden.

Sicherheitsverantwortliche sollten Authentifizierungslogs und Verbindungsversuche – auch von localhost – aktiv ueberwachen, um auffaellige Muster fruehzeitig zu erkennen. Gleichzeitig ist es sinnvoll, die KI-Agenten strikt nach dem Prinzip der geringsten Privilegien zu konfigurieren: nur die unbedingt notwendigen API-Schluessel, Rollen und Systemrechte sollten vergeben werden, um den Schaden bei einer eventuellen Kompromittierung zu begrenzen.

Der Vorfall um ClawJacked verdeutlicht, dass Dienste auf localhost nicht automatisch als sicher gelten duerfen, sobald ein moderner Browser ins Spiel kommt. Organisationen, die self-hosted KI-Assistenten und autonome Agentensysteme einsetzen, sollten ihre Bedrohungsmodelle ueberarbeiten, WebSocket- und localhost-Risiken explizit einbeziehen und Sicherheitsupdates konsequent einspielen. Wer diese Systeme fruehzeitig sicher architektonisch einbettet, senkt die Wahrscheinlichkeit deutlich, dass der eigene KI-Assistent eines Tages als Einfallstor fuer Angreifer dient.

Schreibe einen Kommentar

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre, wie deine Kommentardaten verarbeitet werden.