Banner E-Learning IT-Sicherheit
Free

Ein Klick genügt: Kritische Lücke ermöglicht Code-Ausführung über bösartigen Link : Schwere Schwachstelle in OpenClaw erlaubt vollständige Übernahme lokaler Systeme

Eine kritische Schwachstelle im Open-Source-Projekt OpenClaw macht deutlich, wie riskant Designfehler in lokalen KI-Agenten sind. Ein einziger präparierter Link genügt, um ohne weitere Nutzeraktion fremden Code auszuführen und die vollständige Kontrolle über den lokalen Gateway-Dienst zu übernehmen.

Eine Sicherheitslücke mit hohem Schweregrad in OpenClaw – früher auch unter den Namen Clawdbot und Moltbot bekannt – erlaubt eine Remote Code Execution per Mausklick. Die Schwachstelle wird unter CVE-2026-25253 geführt und erreicht einen CVSS-Wert von 8,8. Microsoft-unabhängig, aber sicherheitsrelevant für Windows-, Linux- und Mac-Systeme, wurde sie mit Version 2026.1.29 am 30. Januar 2026 behoben.

OpenClaw ist ein quelloffener, autonomer KI-Assistent, der lokal auf den Geräten der Nutzer läuft und sich in eine Vielzahl von Messaging-Plattformen integrieren lässt. Obwohl das Projekt erst im November 2025 veröffentlicht wurde, hat es in den vergangenen Wochen stark an Popularität gewonnen. Das zugehörige GitHub-Repository überschritt zuletzt die Marke von 149 000 Sternen.

OpenClaw ist eine offene Agentenplattform, die auf dem eigenen System läuft und direkt aus den Chat-Anwendungen heraus arbeitet, die man ohnehin nutzt“, so Peter Steinberger, Entwickler und Maintainer des Projekts. „Im Gegensatz zu Software-as-a-Service-Assistenten, bei denen die Daten auf fremden Servern liegen, läuft OpenClaw dort, wo der Nutzer es möchte – auf dem Laptop, im Homelab oder auf einem virtuellen Server. Eigene Infrastruktur. Eigene Schlüssel. Eigene Daten.“

Vertrauensbruch in der Control-Oberfläche

Kern des Problems ist ein Designfehler in der webbasierten Control-Oberfläche. Diese übernimmt eine über die Internetadresse übergebene Gateway-Adresse ungeprüft und stellt beim Laden automatisch eine Verbindung her. Dabei wird ein bereits gespeicherter Zugriffstoken direkt im WebSocket-Verbindungsaufbau mitgesendet.

Steinberger beschreibt das Problem so: „Die Control-Oberfläche vertraut der Gateway-Adresse aus der Abfragezeichenfolge, verbindet sich automatisch und sendet dabei den gespeicherten Gateway-Token.“ Ein einziger Klick auf einen präparierten Link reicht aus, um den Token an einen vom Angreifer kontrollierten Server zu übertragen. Dieser kann sich anschließend direkt mit dem lokalen Gateway des Opfers verbinden.

Vom Token zum vollständigen Systemzugriff

Mit dem erbeuteten Token erhält der Angreifer weitreichende Rechte. Dazu gehört die Möglichkeit, Konfigurationen zu verändern, Sicherheitsmechanismen zu deaktivieren und privilegierte Aktionen auszuführen. Das Ergebnis ist eine vollständige Kompromittierung des Gateways inklusive Code-Ausführung auf dem Host-System.

Die drastischen Folgen fasst Steinberger zusammen: „Der Angreifer kann Konfigurationen ändern, privilegierte Aktionen auslösen und erreicht damit eine One-Click-Remote-Code-Ausführung.“

Cross-Site-WebSocket-Hijacking als Angriffsvektor

Entdeckt wurde die Schwachstelle von Mav Levin, Security Researcher bei depthfirst. Er beschreibt den technischen Kern des Angriffs als Cross-Site-WebSocket-Hijacking. Der lokale Server von OpenClaw prüft nicht den Ursprung der WebSocket-Verbindung und akzeptiert Anfragen von beliebigen Webseiten. Das ermöglicht folgendes Angriffsszenario:

  • Opfer besucht eine manipulierte Webseite
  • Clientseitiges JavaScript wird ausgeführt
  • Zugriffstoken wird abgegriffen
  • WebSocket-Verbindung zum lokalen Gateway wird aufgebaut
  • Authentifizierung wird mit gestohlenem Token umgangen

Sicherheitsmechanismen lassen sich gezielt aushebeln

Besonders schwer wiegt, dass der abgegriffene Token mit umfangreichen Berechtigungen ausgestattet ist. Über die Rollen operator.admin und operator.approvals erhält der Angreifer die Möglichkeit, gezielt tiefgreifende Eingriffe vorzunehmen, darunter:

  • Nutzerbestätigungen deaktivieren
  • Sicherheitsabfragen abschalten
  • Den Ausführungsort von Befehlen ändern

Konkret lässt sich die Ausführung von Befehlen aus der Container-Umgebung heraus auf das Host-System verlagern. Levin: „Das zwingt den Agenten dazu, Befehle direkt auf dem Host-System auszuführen und nicht mehr innerhalb eines isolierten Containers.“

Der finale Schritt zur beliebigen Code-Ausführung erfolgt anschließend über einen entsprechenden API-Aufruf.

Sicherheitsarchitektur greift ins Leere

Auf die Frage, ob es sich um ein grundsätzliches Architekturproblem handelt, weist Levin auf eine trügerische Annahme hin: „Diese Schutzmechanismen wie Sandbox und Sicherheitsleitplanken wurden entwickelt, um bösartige Aktionen eines Sprachmodells einzudämmen. Nutzer könnten glauben, dass sie auch vor dieser Schwachstelle schützen – das tun sie jedoch nicht.“

Steinberger schreibt dazu in seiner Sicherheitswarnung: „Die bestehenden Sicherheitsbarrieren waren nie dafür ausgelegt, Angriffe aus dem Browser-Kontext abzuwehren.“

Auch lokale Instanzen betroffen

Besonders brisant: Selbst Instanzen, die ausschließlich an die lokale Loopback-Adresse gebunden sind, sind angreifbar. Wie Steinberger betont, fungiert der Browser des Opfers als Brücke nach außen. Damit funktioniert der Angriff auch in vermeintlich isolierten Umgebungen.

Betroffen sind alle Moltbot– und OpenClaw-Installationen, bei denen sich ein Nutzer zuvor an der Control-Oberfläche angemeldet hat.

Handlungsempfehlungen

Die Schwachstelle in OpenClaw macht deutlich, dass lokal betriebene KI-Agenten mit Webschnittstellen ein neues und bislang häufig unterschätztes Angriffsfeld darstellen. Anders als klassische Serverdienste kombinieren sie lokale Ausführung, weitreichende Automatisierung und browserbasierte Steuerung. Dadurch entstehen neue Angriffsvektoren, bei denen bereits ein einzelner Klick auf einen manipulierten Link ausreichen kann, um vollständige Kontrolle über das System zu erlangen.

Für Betreiber und Anwender ergeben sich daraus unmittelbare Handlungsanforderungen:

  • Sofortige Aktualisierung auf eine abgesicherte Version, um bekannte Schwachstellen zu schließen
  • Rotation aller Zugriffstokens, da kompromittierte Tokens weiterhin missbraucht werden könnten
  • Einschränkung und Absicherung von Webschnittstellen, insbesondere durch Origin-Prüfungen und explizite Freigaben
  • Überprüfung von Berechtigungen, um sicherzustellen, dass Tokens nur minimal notwendige Rechte besitzen
  • Monitoring von API- und WebSocket-Zugriffen, um ungewöhnliche Verbindungen frühzeitig zu erkennen

Langfristig zeigt der Vorfall, dass bestehende Sicherheitskonzepte für KI-Agenten erweitert werden müssen. Schutzmechanismen, die primär auf die Kontrolle von Prompts und Modellausgaben ausgelegt sind, greifen bei infrastrukturellen Schwachstellen nicht. Künftige Sicherheitsarchitekturen müssen daher Webschnittstellen, Token-Management, Browser-Interaktionen und lokale Ausführungsrechte gleichermaßen berücksichtigen, um das tatsächliche Risiko solcher Systeme wirksam zu begrenzen.