ClawJacked: Jede Website könnte einen lokalen OpenClaw-Agenten per Brute-Force attackieren

ClawJacked, eine von Oasis Security am 26. Februar 2026 in dem Open-Source-KI-Agenten OpenClaw offengelegte Schwachstelle, ermöglichte es jeder Website, die ein Entwickler besuchte, eine Verbindung zum Agenten auf dem eigenen Rechner zu öffnen und dessen Passwort zu erraten, bis dieser die Kontrolle abgab. Weder ein Klick noch ein Plugin noch ein Prompt waren nötig. Der Preis war das Gateway, das den Agenten orchestriert: Ein Eindringling, der hineinkam, konnte direkt mit dem Agenten sprechen, seine Konfiguration auslesen, jedes gekoppelte Gerät auflisten und seine Protokolle lesen. Oasis, ein Anbieter von Software für agentisches Zugriffsmanagement, demonstrierte die Kette durchgängig im eigenen Labor und meldete sie vertraulich, und OpenClaw lieferte innerhalb von weniger als 24 Stunden einen Fix aus. Keine in diesem Artikel zitierte Quelle dokumentiert, dass der Angriff gegen einen realen Nutzer eingesetzt wurde. Das Archiv führt den Vorfall als Infrastrukturvorfall mit hohem Schweregrad mit einem Datum mit Tagesgenauigkeit – dem 25. Februar 2026 – und ohne dokumentierten realen Schaden, zusammen mit den übrigen OpenClaw-Einträgen im Orca AI Incident Archive.

Drei Voreinstellungen, eine Kette

OpenClaw ist ein selbst gehosteter persönlicher Agent, den seine Nutzer über ein Web-Dashboard oder ein Terminal steuern und der sich mit Messaging-Apps, Kalendern und Entwicklertools verbindet und darin agiert. Im Zentrum steht ein Gateway, ein lokaler WebSocket-Server, den Oasis als „das Gehirn des Ganzen“ beschreibt: Es übernimmt die Authentifizierung, speichert die Konfiguration, verwaltet Chat-Sitzungen und leitet Befehle an Knoten wie eine macOS-Begleit-App oder ein iPhone weiter. Die Authentifizierung erfolgt per Token oder Passwort, und das Gateway bindet standardmäßig an localhost, unter der ausdrücklichen Annahme, dass lokaler Zugriff inhärent vertrauenswürdig ist (Oasis Security, 26. Februar 2026).

Drei miteinander verkettete Folgen dieser Annahme. Erstens wenden Browser Cross-Origin-Regeln nicht in derselben Weise auf WebSocket-Verbindungen an wie auf gewöhnliche HTTP-Anfragen, sodass JavaScript auf jeder vom Benutzer besuchten Seite einen Socket zum lokalen Gateway-Port öffnen kann, ohne dass auf dem Bildschirm etwas sichtbar ist. Zweitens nahm der Ratenbegrenzer des Gateways Loopback-Verbindungen vollständig aus, sodass fehlgeschlagene Passwortversuche von 127.0.0.1 nicht gezählt, gedrosselt oder protokolliert wurden. Drittens genehmigte das Gateway Gerätekopplungen von localhost automatisch, sodass sich ein authentifiziertes Skript als vertrauenswürdiges Gerät registrieren konnte, ohne die Bestätigungsaufforderung, die ein entferntes Gerät auslösen würde.

Oasis hat die Rate der Passwortrateversuche im eigenen Labor gemessen und in der Offenlegung angegeben: „In unseren Labortests erreichten wir allein mit Browser-JavaScript eine dauerhafte Rate von Hunderten von Passwortrateversuchen pro Sekunde. Bei dieser Geschwindigkeit ist eine Liste gängiger Passwörter in unter einer Sekunde erschöpft, und ein großes Wörterbuch würde nur Minuten dauern. Ein von Menschen gewähltes Passwort hat keine Chance.“ BleepingComputer, das am 1. März 2026 über die Offenlegung berichtete, beschreibt dieselben drei Schritte und dieselbe Reihenfolge.

Was ein Angreifer bekommt und was Oasis tatsächlich gezeigt hat

Nach der Authentifizierung verfügte das Skript über eine Operatorsitzung mit Berechtigungen auf Admin-Ebene. Oasis nennt vier Dinge, die es dann direkt tun kann: Nachrichten an den KI-Agenten senden und dessen Antworten lesen, die Gateway-Konfiguration ausgeben, die die verwendeten KI-Anbieter, Modelle und Messaging-Kanäle offenlegt, jeden verbundenen Knoten samt Plattform und IP-Adresse auflisten und die Anwendungsprotokolle lesen. Von dort aus beschreibt Oasis die Eskalation, statt sie zu demonstrieren: den Agenten anzuweisen, die Slack-Historie des Entwicklers nach API-Schlüsseln zu durchsuchen, private Nachrichten zu lesen, Dateien von gekoppelten Geräten zu exfiltrieren oder beliebige Shell-Befehle auf jedem gekoppelten Knoten auszuführen. Die Zusammenfassung des Ergebnisses durch die Firma lautet, dass dies für einen Entwickler mit typischen OpenClaw-Integrationen auf eine „vollständige Kompromittierung der Workstation, ausgelöst von einem Browser-Tab“ hinausläuft.

Die Demonstration, die Oasis mit einem Video-Proof-of-Concept veröffentlichte, ist weniger weitreichend als diese Beschreibung: Ein Browser auf einer nicht damit zusammenhängenden Website erriet das Gateway-Passwort, verband sich mit vollen Berechtigungen und interagierte erfolgreich mit dem Agenten des Nutzers, ohne dass dem Nutzer ein Hinweis angezeigt wurde. Die Exfiltration von Dateien und die Shell-Ausführung werden als das beschrieben, was der Zugriff ermöglicht, nicht als Schritte, die der Proof of Concept ausgeführt hat. Dieser Unterschied ist von Bedeutung, wenn die Aufzeichnung als ein tatsächlich eingetretener Vorfall und nicht als eine Demonstration gelesen wird.

Der Patch ist in 2026.2.25 gelandet, nicht in 2026.2.26.

Oasis riet Lesern, auf Version 2026.2.25 oder höher zu aktualisieren, und der eigene Sicherheitshinweis von OpenClaw stimmt dem zu. Der GitHub-Advisory GHSA-jmmg-jqc7-5qf4 listet betroffene Versionen als 2026.2.24 und früher, gepatchte Versionen als 2026.2.25 und höher auf und schreibt den Bericht @luz-oasis zu, dem Oasis-Forschungsleiter Elad Luz. Der npm-Registry-Zeitstempel für 2026.2.25 ist der 26. Februar 2026, 04:16 UTC, und die Versionshinweise des Projekts für diese Version beschreiben den Fix mit Formulierungen, die sich eins zu eins auf die drei Standardeinstellungen abbilden lassen: „Security/Gateway WebSocket auth: enforce origin checks for direct browser WebSocket clients beyond Control UI/Webchat, apply password-auth failure throttling to browser-origin loopback attempts (including localhost), and block silent auto-pairing for non-Control-UI browser clients.“

Zwei der Nachrichtenberichte nennen eine andere Nummer. BleepingComputer schreibt, der Fix sei „in Version 2026.2.26 am 26. Februar veröffentlicht“ worden, und SecurityAffairs wiederholt, dass 2026.2.26 die Version gewesen sei, die das Problem behoben habe, während der eigene Ratabsatz Leser dazu auffordert, auf 2026.2.25 oder neuer zu aktualisieren. Infosecurity Magazine, das über die Offenlegung am 2. März 2026 berichtet, nennt 2026.2.25. Release 2026.2.26 existiert zwar, aber npm verzeichnet ihn um 23:59 UTC am 26. Februar, rund zwanzig Stunden nach 2026.2.25, und seine Hinweise sind eine separate Sammlung von Härtungsmaßnahmen. Der Fix, nach dem ein Leser suchen sollte, ist der in 2026.2.25.

Der Bezeichner kam später. Der GitHub-Sicherheitshinweis wurde am 3. März 2026 unter CVE-2026-32025 veröffentlicht, und NVDs Eintrag dazu wurde am 19. März 2026 mit einem CVSS-3.1-Basisscore von 7,5 veröffentlicht; NVD als primärer Bewerter und VulnCheck als sekundärer Bewerter stufen ihn als hoch ein. Der Hinweis selbst ist vorsichtiger als der Score: Sein eigenes Schweregradfeld lautet mittel, und sein Text bezeichnet den Fehler als „ernst, aber bedingt“ und nennt vier Voraussetzungen – das Gateway über Loopback erreichbar, Passwortauthentifizierung im Einsatz, das Opfer öffnet vom Angreifer kontrollierte Webinhalte und ein Passwort, das mit vertretbaren Versuchen erratbar ist. Außerdem wird klar ausgesagt, was der Fehler nicht ist: „Dies ist für sich genommen kein unauthentifiziertes, internetexponiertes Problem der RCE-Klasse; es ist eine lokale Auth-Härtungslücke mit Browser-Ursprung, die unter den oben genannten Bedingungen spürbare Auswirkungen hat.“

Woher die 42.665 stammt und warum sie keine ClawJacked-Zahl ist

Die Zusammenfassung des Archivs verzeichnet, dass zum Zeitpunkt der Offenlegung 42.665 Instanzen exponiert waren, und merkt an, dass SecurityScorecard eine abweichende Zahl von 40.214 nennt, von denen 35,4 % anfällig waren. Keine der drei für diesen Eintrag zitierten Quellen enthält eine der beiden Zahlen – Oasis, BleepingComputer und SecurityAffairs beschreiben die Schwachstelle allesamt, ohne eine Anzahl der installierten Basis anzugeben. Beide Zahlen stammen von woanders, und beide wurden veröffentlicht, bevor ClawJacked existierte.

Die Zahl 42.665 stammt aus einem unabhängigen Scan. Maor Dayan, ein Sicherheitsforscher, der seine Ergebnisse auf Medium veröffentlichte, entwickelte einen Scanner namens ClawdHunter v3.0 und ließ ihn über Daten von Shodan und Censys laufen, die zwischen dem 28. und 31. Januar 2026 erhoben wurden; er meldete „mindestens 42.665 Instanzen“ von OpenClaw, die öffentlich im Internet exponiert waren, wovon 5.194 aktiv als verwundbar verifiziert wurden und bei 93,4 % der verifizierten eine Authentifizierungsumgehung auftrat. Die Zahl 40.214 stammt vom STRIKE-Team von SecurityScorecard aus einer am 9. Februar 2026 veröffentlichten Untersuchung, in der internetexponierte OpenClaw-Instanzen gezählt und 15,2K als anfällig für Remote Code Execution gekennzeichnet wurden, wobei „35,4 % der beobachteten Bereitstellungen als verwundbar eingestuft wurden“. Die eigenen Zusammenfassungspunkte von SecurityScorecard nennen 42,9K eindeutige IP-Adressen, die exponierte Steuerungsoberflächen hosten, neben den 40.214 bestätigten Instanzen im Fließtext — zwei unterschiedliche Messungen innerhalb eines Berichts.

Keine der beiden Zahlen misst die Reichweite von ClawJacked, denn beide zählen Instanzen, die auf einer öffentlichen Schnittstelle antworten. Die Voraussetzung von ClawJacked ist die entgegengesetzte Konfiguration: ein Gateway, das an Loopback gebunden ist, im Passwortmodus, auf einem Rechner, dessen Benutzer eine feindliche Seite besucht. Ein Server, der in einem internetweiten Scan gezählt wird, kann hinter seiner eigenen Authentifizierung sitzen und von diesem Fehler unberührt bleiben, während der Laptop, der in einem solchen Scan nie auftaucht, genau das von Oasis beschriebene Ziel ist. Die eigene Formulierung des Archivs, „at disclosure“, verknüpft daher eine Bestandszahl vom Januar mit einer Schwachstelle vom Februar. Die Zahlen sind echte Messungen davon, wie stark OpenClaw exponiert war; sie sind keine Zählung der Maschinen, die ClawJacked hätte übernehmen können. Dieser Artikel entscheidet keinen Streit — der Eintrag ist nicht als strittig markiert —, aber die Herkunft der beiden Zahlen ist überprüfbar und stützt die Formulierung „at disclosure“ nicht.

Was gilt als gesichert und was nicht

Belegt: dass Oasis Security die Kette gefunden und im Labor demonstriert hat; dass der eigene Sicherheitshinweis und die Versionshinweise von OpenClaw alle drei Verhaltensweisen bestätigen — fehlende Durchsetzung der Origin-Prüfung für Browser-WebSocket-Clients, fehlende Ratenbegrenzung bei Passwortversuchen über Loopback, stille automatische Kopplung — und dass 2026.2.25 jede davon geändert hat; dass der Fix innerhalb eines Tages nach dem Bericht ausgeliefert wurde; und dass drei Medien außerhalb des eigenen Blogs des Finders darüber berichteten. Die Vertrauensstufe A des Archivs steht im Einklang mit dieser Beweislage, und nichts hier wird von den beteiligten Parteien bestritten.

Nicht belegt: dass es jemand genutzt hat. Hier wird keine Quelle genannt, und auch in der Berichterstattung rund um die Offenlegung wurde keine gefunden, die eine reale Kompromittierung, ein Opfer oder entwendete Daten meldet. Bei Oasis handelt es sich um eine Labordemonstration, und die Ausarbeitung beschreibt Angreiferfähigkeiten statt eines beobachteten Angriffs. Das deckt sich damit, dass das Archiv keinen realen Schaden verzeichnet, und es ist die wichtigste Einschränkung bei dieser Geschichte: Dies ist ein Schwachstellenbericht, kein Bericht über eine Datenpanne.

Zwei kursierende Bezeichnungen sind falsch, und beide werden leicht übernommen. Mehrere sekundäre Berichte verbinden CVE-2026-25253 mit ClawJacked. Der NVD-Eintrag zu dieser Kennung beschreibt einen anderen Fehler im selben Produkt: OpenClaw vor 2026.1.29 übernimmt eine gatewayUrl aus einem Query-String und stellt ohne Nachfrage eine Verbindung dorthin her, während ein Token gesendet wird – ein Token-Diebstahl per Ein-Klick mit einem CVSS-Score von 8,8, veröffentlicht am 1. Februar 2026 und behoben am 29. Januar. Das ist die Januar-Schwachstelle, mit einem anderen Mechanismus und einem anderen Patch. Die Kennung von ClawJacked ist CVE-2026-32025. Infosecurity Magazine beschrieb ClawJacked unterdessen als indirekte Prompt-Injection; die von Oasis dokumentierte Kette beinhaltet überhaupt keinen Prompt und keine Modellentscheidung – sie ist eine Umgehung der Authentifizierung, die in einer Operator-Sitzung endet.

Was hat sich danach geändert?

OpenClaw hat die Lücke geschlossen, die Sicherheitsmeldung veröffentlicht und den Melder genannt, und die CVE wurde innerhalb einer Woche nach der öffentlichen Veröffentlichung zugewiesen. Die Empfehlungen von Oasis an Organisationen gehen über den Patch hinaus: Erfassen Sie, welche Agenten und Assistenten auf den Entwicklerrechnern laufen, aktualisieren Sie jede Instanz, prüfen Sie, über welche Zugangsdaten und Fähigkeiten jeder einzelne verfügt, und entziehen Sie, was nicht genutzt wird, und steuern Sie Agenten als nicht-menschliche Identitäten mit Absichtsprüfungen, Richtliniendurchsetzung, Just-in-Time-Zugriff und einem Audit-Trail vom Menschen über den Agenten bis zur Aktion. Das Unternehmen verkauft Software in der letztgenannten Kategorie, was man wissen sollte, wenn man die letzte Empfehlung gegen die ersten drei abwägt.

Der größere Zusammenhang ist, dass ClawJacked nur ein Sicherheitshinweis in einer Flut war. Die GitHub Advisory Database enthält eine große Charge von OpenClaw-Advisories vom 3. März 2026 – am selben Tag, an dem ClawJackeds eigener veröffentlicht wurde –, die separate Fehler bei Authentifizierung, Pairing, Path-Traversal und Sandbox-Escape über die Versionen 2026.2.19 bis 2026.2.26 abdecken. Das Muster, das der ClawJacked-Eintrag festhält, ist enger als „KI-Agenten sind unsicher“ und nützlicher: Das Gateway behandelte Loopback als Vertrauensgrenze, und der Browser machte diese Annahme falsch. Jeder lokale Dienst, der 127.0.0.1 von Drosselung ausnimmt, und jeder Geräte-Pairing-Ablauf, der lokale Aufrufer automatisch genehmigt, erbt dieselbe Form, ob ein KI-Modell dahintersteht oder nicht. In diesem Fall war das Modell nie die anfällige Komponente – die Authentifizierungsschicht darum herum war es.