Mehrere Hackergruppen nutzen OpenClaw-Instanzen aus, um API-Schlüssel zu stehlen und Malware zu installieren

OpenClaw hat sich in Rekordzeit vom "interessanten KI-Agentenprojekt" zum "aktiven Sicherheitsziel" entwickelt. Jüngste Berichte beschreiben mehrere Bedrohungsakteure, die OpenClaw-Einsätze ausnutzen, um API-Schlüssel zu stehlen und bösartige Nutzdaten zu übermitteln, während parallele Untersuchungen und Empfehlungen ein breiteres Muster zeigen: Es handelt sich nicht um einen einzelnen Fehler, sondern um ein Sicherheitsproblem auf Ökosystemebene, das exponierte Steuerungsebenen, Annahmen zu lokalen Privilegien, unsicheres Vertrauen in Erweiterungen und Agenten-Workflows umfasst, die die Grenze zwischen Daten und Anweisungen verwischen. (Nachrichten zur Cybersicherheit)

Wenn Sie ein Sicherheitsingenieur sind, ist nicht nur die Schlagzeile wichtig. Es ist das wiederholbare Modell hinter den Vorfällen:

• Ein hochprivilegierter lokaler Agent sammelt Geheimnisse
• Es stellt Schnittstellen zur Verfügung (Web, WebSocket, Chat, Skills, Logs)
• Benutzer installieren Funktionen von Drittanbietern
• Angreifer verketten Social Engineering + Designfehler + schwache Standardeinstellungen
• Verteidiger flicken ein Problem, verpassen aber die operative Exposition

Dieses Muster macht OpenClaw zu einer so nützlichen Fallstudie für die Sicherheit von KI-Agenten im Jahr 2026. Die Advisory-Seiten von GitHub und die Advisory-Listen des OpenClaw-Repository zeigen auch einen schnelllebigen Strom neu veröffentlichter Sicherheitskorrekturen, was genau das ist, was man bei einem Projekt erwartet, das schneller skaliert als sein Bedrohungsmodell ausgereift ist. (GitHub)

In diesem Artikel werden die jüngste Angriffswelle, die wichtigsten Schwachstellen und Hinweise, das Malware-Problem auf dem Skill-Marketplace und die praktischen Kontrollen, die Teams sofort einsetzen sollten, aufgeschlüsselt. Außerdem enthält er eine defensive Erkennungslogik, Validierungschecklisten und Beispiel-Automatisierungsmuster, die Sicherheitsteams anpassen können, ohne etwas zu bewaffnen.

Was geschah bei der jüngsten OpenClaw-Angriffswelle?

Ein kürzlich veröffentlichter Bericht beschreibt weitverbreitete Ausnutzung von OpenClaw (ehemals MoltBot / Clawdbot) von mehreren Hackergruppen, um bösartige Nutzdaten zu verteilen und API-Schlüssel von ungeschützten oder schwach geschützten Instanzen zu stehlen. In der Berichterstattung wird dies als aktiver Kampagnentrend und nicht als rein theoretisches Risiko dargestellt, was sich mit der allgemeinen Tendenz der jüngsten OpenClaw-Berichterstattung deckt. (Nachrichten zur Cybersicherheit)

Gleichzeitig wurde in separaten Berichten und Analysen dokumentiert:

• Internet-exponierte OpenClaw-Einsätze in großem Maßstabje nach Scan-Methode/Zeitfenster Tausende bis Zehntausende von erreichbaren Instanzen enthalten. Hunt.iozum Beispiel, berichtete über 17.500 exponierte Instanzen in einer Analyse, die sich auf die Suche nach CVE-2026-25253 konzentrierte. (jagen.io)
• Bösartige Fähigkeiten in ClawHub / dem OpenClaw-ErweiterungsökosystemDie Mainstream-Berichterstattung zitiert die Ergebnisse zahlreicher bösartiger Add-ons/Skills, die über Social Engineering und das Verhalten ausführbarer Erweiterungen auf Anmeldeinformationen und Kryptowährungen abzielen. (The Verge)
• Mehrere Sicherheitshinweise und CVEs die sich auf zentrale Verhaltensweisen wie Token-Lecks, unsichere Konfigurationsanwendungen und Protokollierungspfade auswirken, die sicherheitsrelevant werden, wenn sie in KI-gestützte Arbeitsabläufe eingespeist werden. (NVD)

Mit anderen Worten: Das aktuelle OpenClaw-Problem lässt sich am besten als zusammengesetzte Angriffsfläche:

1. Expositionsrisiko (internetfähige Steuerungsebenen)
2. Risiko der Verwundbarkeit (bekannte CVEs/Hinweise)
3. Risiko in der Lieferkette (Fähigkeiten / Erweiterungen)
4. Workflow-Risiko (Protokolle, Eingabeaufforderungen, KI-gestützte Fehlersuche)
5. Operationelles Risiko (Benutzer, die Code patchen, aber keine Geheimnisse wechseln oder Privilegien reduzieren)

Aus diesem Grund reicht "Patchen" allein nicht aus.

Warum OpenClaw so schnell zu einem hochrangigen Ziel wurde

OpenClaw ist für Angreifer aus demselben Grund attraktiv, aus dem es für Benutzer attraktiv ist: Es konzentriert die Fähigkeiten.

In der gängigen Berichterstattung wird OpenClaw als lokaler KI-Agent beschrieben, der Aufgaben im Namen des Benutzers ausführen kann und weitreichenden Zugriff auf lokale Dateien, Skripte, Shell-Befehle und verbundene Dienste erhalten kann. Diese Kombination macht eine Kompromittierung des Agenten zu einem Ausweisdiebstahl Problem und, in vielen Umgebungen, ein seitliche Bewegung Problem. (The Verge)

Dies verändert die Wirtschaftlichkeit von Angriffen:

• Ein erfolgreicher Kompromiss kann zu folgenden Ergebnissen führen mehrere API-Schlüssel (LLM-Anbieter, Cloud-Tools, Messaging-Plattformen).
• Der Agent kann als zuverlässiger Stellvertreter.
• Skill-Ökosysteme schaffen ein Vertriebskanal für bösartige Logik.
• Zu den Benutzern gehören Entwickler und Power-User mit privilegierten Umgebungen.

Angreifer brauchen nicht jedes Mal einen perfekten Exploit. Sie können durch eine Kombination aus schwacher Bereitstellung, übermäßigen Integrationen und Social Engineering gewinnen.

Der Wechsel des zentralen Bedrohungsmodells: Von der "App-Schwachstelle" zum "Agent Control-Plane-Missbrauch"

Herkömmliche Sicherheitskategorien für Webanwendungen sind nach wie vor von Bedeutung (RCE, Umgehung der Autorisierung, Befehlsinjektion, Path Traversal, SSRF usw.), aber OpenClaw fügt ein neues und subtileres Problem hinzu: der Agent selbst ist ein Ausführungs-Orchestrator.

Dadurch entstehen drei Sicherheitsgrenzen, die Verteidiger explizit modellieren müssen:

1) Grenze des Vertrauens zwischen Mensch und Akteur

Die Benutzer vertrauen dem Assistenten, dass er ihre Absichten sicher ausführt. Angreifer missbrauchen dies durch bösartige Links, bösartige Fähigkeiten, gefälschte Einrichtungsanweisungen oder Manipulationen auf der Eingabeaufforderungsebene.

2) Vertrauensgrenze zwischen Agent und System

Der Agent kann Zugriff auf Shell-Ausführung, lokale Dateien, Token und Netzwerkressourcen haben. Sobald der Agent manipuliert wird, wird er zu einer privilegierten Ausführungsoberfläche.

3) Daten-zu-Befehl-Grenze

Protokolle, Markdown, Kommentare und "hilfreicher Text" können später von LLM-Workflows verwendet werden. GitHubs GHSA-g27f-9qjv-22pm ist ein gutes Beispiel dafür, wie selbst ein Protokollierungspfad sicherheitsrelevant werden kann, wenn Protokolle von KI-gestützten Debugging-Systemen gelesen werden. (GitHub)

Aus diesem Grund unterschätzen viele Teams zunächst das OpenClaw-Risiko: Sie verteidigen den Code-Pfad, den sie kennen, aber nicht den Workflow-Pfad, den sie erstellt haben.

Die wichtigsten OpenClaw-Sicherheitslücken und -Hinweise im Moment

Nachfolgend sind die wichtigsten Punkte aufgeführt, die bei der Analyse der aktuellen OpenClaw-Ausbeutungslandschaft zu beachten sind. Dies sind nicht die einzigen Probleme, aber sie sind sehr aufschlussreich, da sie häufigen Fehlermöglichkeiten in der Praxis entsprechen.

CVE-2026-25253: Gateway URL / Token Exposure Chain

NVD beschreibt CVE-2026-25253 als ein Problem in OpenClaw (aka Clawdbot / Moltbot) vor 2026.1.29, bei dem ein gatewayUrl Wert kann aus einem Query-String gewonnen werden und OpenClaw stellt automatisch eine WebSocket-Verbindung ohne Aufforderung her und sendet einen Token-Wert. NVD listet CVSS v3.1 Vektor AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H und CWE-669. (NVD)

Diese Schwachstelle ist bemerkenswert, weil sie ein wiederkehrendes Anti-Sicherheitsmuster bei Agenten demonstriert:

• Benutzergesteuerter Eingang beeinflusst das Routing in der Steuerungsebene
• Automatisches Verbindungsverhalten erfolgt ohne starke Validierung/Aufforderung
• Sensible Token werden als Teil des Workflow-Status übermittelt

Dies deckt sich auch mit der öffentlichen Berichterstattung über "Ein-Klick"-Angriffsszenarien und Token-Diebstahlsrisiken in OpenClaw-Ökosystemen. (depthfirst.com)

CVE-2026-25593: Lokale WebSocket-Konfigurations-Schreib-Befehls-Injektion

NVD beschreibt CVE-2026-25593 als eine Schwachstelle, bei der vor 2026.1.20 ein nicht authentifizierter lokaler Client die Gateway WebSocket API verwenden konnte, um die Konfiguration über config.apply und unsicher machen cliPath Werte, die später für die Befehlsermittlung verwendet werden, was die Befehlsinjektion als Gateway-Benutzer ermöglicht. NVD weist auf den Fix in 2026.1.20 hin. (NVD)

Dies ist aus betrieblicher Sicht von Bedeutung, da viele Teams ein "nur lokales" Risiko als gering einstufen. In Entwicklerumgebungen ist diese Annahme oft falsch, weil:

• Browser-unterstützte Localhost-Zugriffsmuster
• bereits vorhandene lokale Malware
• Port-Weiterleitungen / Reverse-Proxies
• unsicheres Vertrauen in "gleiche Maschine == sichere Maschine"

GHSA-g27f-9qjv-22pm: Vergiftung von Protokollen über WebSocket-Header (Risiko einer indirekten Prompt-Injektion)

In der Advisory-Datenbank von GitHub heißt es, dass OpenClaw in Versionen vor 2026.2.13 bestimmte WebSocket-Anfrage-Header protokollierte (einschließlich Herkunft und Benutzer-Agent) ohne Neutralisierung oder Längenbegrenzung auf einem "closed before connect"-Pfad. GitHub weist ausdrücklich darauf hin, dass, wenn ein nicht authentifizierter Client das Gateway erreichen und manipulierte Header-Werte senden kann, diese Werte in die Protokolle geschrieben werden können, und wenn die Protokolle später von einem LLM gelesen/interpretiert werden, kann dies das Risiko einer indirekten Prompt Injection (Log Poisoning) erhöhen. Die gepatchte Version ist als 2026.2.13 aufgeführt. (GitHub)

Dies ist eines der deutlichsten Mainstream-Beispiele für eine moderne KI-Agenten-Sicherheitslektion:

Ein Problem, das in einem klassischen Anwendungsmodell von geringer Schwere ist, kann in einem KI-gestützten Arbeitsablauf von großer Bedeutung sein.

GitHub stuft das Advisory als wenig schwerwiegend (CVSS 3.1) ein und weist darauf hin, dass die Auswirkungen begrenzt sind, wenn Sie die Protokolle nicht in ein LLM oder eine andere Automatisierung einspeisen. Diese Konditionalität ist genau das, was ausgereifte Verteidiger in ihrem Bedrohungsmodell beibehalten müssen, anstatt alles in "kritisch" oder "nichts" zu verwandeln. (GitHub)

Das umfassendere Bild der Beratung

Die OpenClaw GitHub Sicherheitshinweise Seite zeigt einen beträchtlichen und aktiven Strom von veröffentlichten Problemen, einschließlich mehrerer moderater/hoch Punkte Ende Februar 2026. Die genaue Liste entwickelt sich schnell, aber das Wichtigste ist, dass die Angriffsfläche von OpenClaw breit ist und aktiv unter echtem Druck gehärtet wird. (GitHub)

Für die Verteidiger bedeutet dies, dass die Kadenz der Aufnäher mit folgenden Faktoren kombiniert werden muss risikobasierte Prioritätensetzung und Umweltprüfungund nicht nur "aufrüsten, wenn es passt".

Das Skills Ecosystem Problem: Wenn "Erweiterungen" zu Malware werden

Das Skill-Ökosystem von OpenClaw (einschließlich der Verweise auf ClawHub in der Berichterstattung) ist der Punkt, an dem viele Teams unvorbereitet getroffen werden. Mehrere Medien berichteten über bösartige Skills, die sich als nützliche Tools tarnen (insbesondere Krypto-/Handelsthemen) und durch Social Engineering und ausführbares Verhalten Malware zum Diebstahl von Informationen liefern. Die Berichterstattung unterstreicht auch, dass Skills keine harmlosen Metadaten sind - sobald sie installiert und aktiviert sind, können sie mit lokalen Dateien und Netzwerken interagieren. (The Verge)

The Verge berichtete über die Ergebnisse von OpenSourceMalware und beschrieb die Malware in Hunderten von durch Benutzer eingereichten Skills, einschließlich Verhalten, das darauf abzielt, Kryptowährungen, API-Anmeldeinformationen, SSH-Anmeldeinformationen und Browser-Passwörter zu stehlen. Der Bericht verweist auch auf die wachsende Popularität von OpenClaw und die weitreichenden lokalen Befugnisse, die einige Benutzer ihm einräumen. (The Verge)

Tom's Hardware berichtete ebenfalls über bösartige Skills, die auf ClawHub hochgeladen wurden, und betonte, dass es sich bei Skills um ausführbare Code-Ordner (und nicht um Skripte mit Sandbox) handelt, und dokumentierte Social-Engineering-Muster, die Benutzer anweisen, verschleierte Terminalbefehle einzufügen, die entfernte Nutzdaten abrufen. (Toms Hardware)

Dies ist nicht nur eine "Malware auf einem Marktplatz"-Geschichte. Es ist eine Verstärkung der Rechte des Agenten Geschichte:

• Erweiterungscode erbt das Vertrauen des Benutzers und oft auch die Rechte des Agenten
• Dokumentation/Einrichtungsabläufe können als Waffe eingesetzt werden
• Manuelle Befehlsausführungsschritte umgehen einige konventionelle Scans
• Benutzer können Fähigkeiten nach ihrem Nutzen und nicht nach der Qualität der Codeüberprüfung bewerten.

Warum dies anders aussieht als das herkömmliche Risiko einer Paketregistrierung

Paket-Ökosysteme (npm, PyPI usw.) bergen bereits Risiken in der Lieferkette, aber OpenClaw-ähnliche Fähigkeiten fügen ein besonderes Muster hinzu:

• Das "Installationsprogramm" kann in Wirklichkeit eine Anleitung in Markdown/Docs sein
• Der Agent ist dazu bestimmt, Aktionen auszuführen
• Benutzer sind darauf konditioniert, automatisierungsorientierte Einrichtungsschritte zu befolgen
• Die Nutzlast kann eine Mischung aus KI-Eingabeaufforderungen + Skriptausführung + externe Abrufe sein

Dieses hybride Modell bedeutet, dass Verteidiger nicht nur Codesignaturen und Hashes prüfen müssen, sondern auch Verhaltensabsicht, Einrichtungsanweisungen und domänenübergreifende Kommunikationsmuster.

Die jüngste Ausbeutungsgeschichte ist größer als eine Kampagne

Die Schlagzeile "mehrere Hackergruppen nutzen OpenClaw-Instanzen aus" ist wichtig, weil sie den Übergang von isoliertem Opportunismus zu Nutzung des Ökosystems. Sobald mehrere Akteure auf derselben Plattform zusammenkommen, sind in der Regel drei parallele Entwicklungen zu beobachten:

1. Nachahmungskampagnen Nutzung der öffentlichen Berichterstattung und PoCs
2. Kommodifizierung von Werkzeugen (Skripte/Scanner für exponierte Instanzen)
3. Spezialisierung nach der Ausbeutung (Token-Diebstahl, Loader, Infostealer, Persistenz)

Dies entspricht dem allgemeinen Muster in der Cyberkriminalität: Sobald eine Plattform weit verbreitet ist, exponiert ist und viele Zugangsdaten enthält, wird sie in bestehende Malware- und Zugangsdaten-Diebstahl-Pipelines integriert.

Speziell bei OpenClaw ist der Nutzen für Angreifer ungewöhnlich groß, da ein einziges Opfer die Daten preisgeben kann:

• LLM-Anbieter-API-Schlüssel
• Messaging-Plattform-Tokens
• Automation-Zertifikate
• Browser/Session-Artefakte
• Dateisystemdaten
• Shell-Ausführungspfade

Wie man über den Diebstahl von API-Schlüsseln in OpenClaw-Vorfällen nachdenkt

Die Schlagzeile hebt den Diebstahl von API-Schlüsseln hervor, und das ist genau der Punkt, an dem viele Unternehmen die Auswirkungen unterschätzen.

Warum gestohlene AI/API-Schlüssel nicht nur ein "Abrechnungsrisiko" sind

Sicherheitsteams behandeln den Diebstahl von API-Schlüsseln manchmal als Finanzproblem ("jemand hat unser Kontingent verbraucht"). In OpenClaw-Kontexten können gestohlene Schlüssel unterstützen:

• Exfiltration von Daten
• Missbrauch von integrierten Diensten
• Operative Nachahmung
• Aufklärung über interne Arbeitsabläufe
• Fortbestand durch Re-Automatisierung

Wenn der Agent Zugang zu mehreren Anbietern hat, können Angreifer selektiv den wertvollsten Schlüssel verwenden (z. B. höhere Kontingente, Unternehmensberechtigungen, geringere Überwachungsreife).

Was Verteidiger nach einem Schlüsseldiebstahl tun müssen (über die Rotation hinaus)

Eine ausgereifte Antwort beinhaltet:

1. Drehen der Tasten
2. Prüfung, wo Schlüssel verwendet wurden
3. Identifizieren, welche Daten/Arbeitsabläufe erreichbar waren
4. Überprüfung der Eingabeaufforderungen/Aufgaben/Protokolle des Agenten auf verdächtige Ausführung
5. Neue Basislinie für den Host
6. Überprüfung der Privilegien und Erweiterung des Vertrauens

Ein einfaches Auswechseln des Schlüssels, aber das Beibehalten des gleichen exponierten/überprivilegierten Agenten ist ein wiederkehrender Fehler.

Ein praktisches Angriffskettenmodell für Sicherheitsteams

Nachfolgend finden Sie eine defensive, nicht waffengestützte Abstraktion davon, wie die jüngsten OpenClaw-Kompromittierungen die Risikofaktoren verketten.

Tabelle: Repräsentative OpenClaw-Angriffskettenabschnitte

Bühne	Angreifer Tor	Gemeinsamer Mechanismus	Defender Toter Winkel	Defensiver Vorrang
Erste Entdeckung	Ziele finden	Internet-Scanning, öffentliche Referenzen	"Es liegt an einem seltsamen Hafen, niemand wird es finden"	Exposition beseitigen, Eindringen beschränken
Erster Zugang	Erreichen des Gateways/der Steuerungsebene	Offengelegte UI/WebSocket, lokale Vertrauensannahmen, Installation bösartiger Fähigkeiten	"Local-only"-Annahmen / schwache Autorisierung	Patch + Autorisierung + Netzwerkkontrollen
Zugang zu Anmeldeinformationen	API-Schlüssel/Tokens stehlen	Exportieren von Endpunkten, Diebstahl von Konfigurationen, Infostealer-Payloads	Weiträumig gespeicherte und wiederverwendete Schlüssel	Geheime Rotation + Scoping
Ausführung	Malware/Befehle ausführen	Agententools, Shell-Pfade, Erweiterungscode, vom Benutzer eingefügte Befehle	Agent wird als "Helfer" und nicht als Vollstrecker betrachtet	Geringste Berechtigung + Zulässigkeitslisten
Persistenz/Wiederverwendung	Fuß fassen oder monetarisieren	Neue Fähigkeiten, gestohlene Token, geplante Aufgaben	Schwache Überwachung von Agentenaktionen	Erkennung von Verhaltensweisen + Überprüfung
Verteidigung Umgehung	Hinweis vermeiden	Gemischte Tätigkeit als rechtmäßiger Vertreter	Nicht normalisierte Protokolle / keine Basislinien	Prüfpfade + Regeln für Anomalien

Diese Tabelle ist absichtlich allgemein gehalten, da die genauen Mechanismen je nach Version, Bereitstellung und Benutzerverhalten variieren. Es geht darum, sicherzustellen, dass Ihre Kontrollen die Ketteund nicht nur den ersten Fehler in der Kette.

Ideen zur Erkennung und Verfolgung für SOC- und Sicherheitstechnik-Teams

OpenClaw-Sicherheit ist nicht nur ein Problem der Patch-Verwaltung. Es ist auch ein Problem der Telemetrie.

Was zu sammeln ist

Erfassen Sie zumindest die Daten und bewahren Sie sie auf:

• Reverse-Proxy-Zugriffsprotokolle (falls vorgelagert)
• OpenClaw-Gateway-Protokolle
• Host-Prozess-Erstellungsprotokolle
• ausgehende Netztelemetrie
• Telemetrie der Dateierstellung/Ausführung in den Arbeitsverzeichnissen der Agenten
• Ereignisse zur Installation von Erweiterungen/Fähigkeiten (oder Äquivalente)
• Schlüsselrotation/Geheimniszugriffsereignisse in Ihrem Geheimdienstmanager (falls integriert)

Was zu jagen ist

Konzentrieren Sie sich auf Verhaltensbündel statt auf einzelne Indikatoren:

• Unerwartete WebSocket-Aktivität zu Agenten-Gateways aus nicht vertrauenswürdigen Quellen
• Anomalien in der Kopfzeile (lange/kodierte Werte) auf agentenseitigen Pfaden
• Ungewöhnliche Kindprozesse die von agentenbezogenen Diensten hervorgebracht werden
• Ausgehende Anrufe zu neu gesehenen Domains kurz nach der Installation der Fähigkeiten
• Ausführung von Terminalbefehlen nach der Einrichtung der Erweiterung Aufforderungen
• Schnelle Abfolge von Schlüsselverwendung durch neue IPs nach vermuteter Kompromittierung

Beispiel für ein SIEM-ähnliches Erkennungskonzept (Pseudo-KQL)

// Defensives Jagdkonzept: verdächtige Aktivitäten um OpenClaw-Hostprozesse
let OpenClawProcs = dynamic(["openclaw", "moltbot", "clawdbot"]);
DeviceProcessEvents
| where InitiatingProcessFileName has_any (OpenClawProcs)
| summarize ChildCount = count(), Children = make_set(FileName, 20) by DeviceName, bin(Timestamp, 15m)
| join kind=leftouter (
    DeviceNetworkEvents
    | where InitiatingProcessFileName has_any (OpenClawProcs)
    | summarize RemoteIPs = make_set(RemoteIP, 50), Domains = make_set(RemoteUrl, 50) by DeviceName, bin(Timestamp, 15m)
) on Gerätename, Zeitstempel
| where ChildCount > 5 oder array_length(Domains) > 10
| Projekt Zeitstempel, Gerätename, ChildCount, Kinder, RemoteIPs, Domänen

Dies ist keine Signatur für "die" OpenClaw-Malware-Kampagne. Es ist eine Möglichkeit, zu finden agentengesteuerte Verhaltensausbrüche die eine Überprüfung verdienen.

Beispiel einer YARA-ähnlichen Heuristik für verdächtige Skill-Installationsskripte (konzeptionell)

Regel Suspicious_OpenClaw_Skill_Setup_Instruction_Pattern
{
  meta:
    description = "Kennzeichnet verdächtige OpenClaw-Skill-Dokumente/Skripte, die verschleierte Terminal-Fetch-Exec-Muster pushen"
    author = "Defensives Forschungsmuster"
    caution = "Nur heuristisch; rechne mit falsch positiven Ergebnissen"

  Zeichenketten:
    $a = /curl\\s+.*\\|\\s*(bash|sh)/ nocase
    $b = /python\\s+-c\\\s+["'].*base64/i
    $c = /osascript.*do shell script/i
    $d = /powershell(\\.exe)?\\s+-enc/i
    $e = "diesen Befehl kopieren und einfügen" nocase
    $f = "Deaktivieren Sie Ihr Antivirusprogramm" nocase

  Bedingung:
    2 von ($a,$b,$c,$d,$e,$f)
}

Verwenden Sie dies als Triagehilfe für die Überprüfung von Fähigkeiten, nicht als Ersatz für die eigentliche Analyse.

Härtung von OpenClaw-Einsätzen: Was das Risiko tatsächlich verringert

Sicherheitsteams fragen oft nach einer "Checkliste der besten Praktiken". Die sinnvolle Antwort ist eine Prioritätenfolge, keine riesige Liste.

Priorität 1: Beseitigung der Internetpräsenz von Kontrollschnittstellen

Wenn Ihre OpenClaw-Kontrollschnittstelle oder Ihr Gateway vom öffentlichen Internet aus erreichbar ist, sollten Sie dies zuerst beheben. Mehrere Berichte und Studien zeigen, dass dies eine der häufigsten Ursachen für Kompromittierung und Token-Diebstahl ist. (jagen.io)

Grundlegende Kontrollen:

• Bindung an localhost, wenn möglich
• VPN/Zero Trust-Zugang für die Fernverwaltung erforderlich
• Autorisierung am Reverse-Proxy durchsetzen
• IP-Zulassungsliste Admin-Zugang
• Ratenbegrenzung und Begrenzung der Kopfzeilengröße für agentenseitige Endpunkte

Das GitHub-Advisory für GHSA-g27f-9qjv-22pm erwähnt ausdrücklich die Einschränkung der Gateway-Netzwerkexposition und die Anwendung von Reverse-Proxy-Limits für die Header-Größe als Abhilfemaßnahmen bzw. Abhilfeschritte. (GitHub)

Priorität 2: Schnelles Patchen, aber Überprüfung von Version und Verhalten

Bei den oben erwähnten Schwachstellen spielen die Patch-Versionen eine Rolle:

• CVE-2026-25253: betroffen vor 2026.1.29 (gemäß NVD) (NVD)
• CVE-2026-25593: behoben in 2026.1.20 (gemäß NVD) (NVD)
• GHSA-g27f-9qjv-22pm: gepatcht in 2026.2.13 (laut GitHub-Beratung) (GitHub)

Aber Versionskontrollen sind nicht genug. Teams sollten verifizieren:

• der Dienst tatsächlich neu gestartet wurde
• der exponierte Endpunkt nicht mehr erreichbar ist
• Token wurden gedreht, wenn eine Exposition stattgefunden haben könnte
• Logs/LLM-Workflows nehmen keine nicht vertrauenswürdigen Inhalte auf unsichere Weise auf.

Priorität 3: Verringerung der Rechte von Agenten und des Umfangs von Token

Das OpenClaw-Risiko steigt mit den Berechtigungen. Wenn ein Agent über umfassenden Dateisystemzugriff, Shell-Ausführung und hochwertige OAuth/API-Tokens verfügt, steigt die Gefahr einer Kompromittierung drastisch an.

Empfohlene Änderungen:

• getrennte Identitäten/Konten für die Nutzung durch Agenten
• geringste Berechtigung für API-Bereiche
• kurzlebige Ausweise, wenn möglich
• keine Cloud-Tokens auf Admin-Ebene
• keine ständigen Produktionsgeheimnisse auf persönlichen Geräten
• Isolierung der Agentenlaufzeit von den Geheimnissen der Entwickler-Workstation

Die Empfehlungen von Eye Security in Bezug auf Aktualisierungen, geringste Rechte und die Vermeidung streng vertraulicher API-Verbindungen, sofern nicht erforderlich, gehen in diese Richtung. (Augenforschung)

Priorität 4: Fertigkeiten als ausführbare Abhängigkeiten behandeln (weil sie es sind)

In der allgemeinen Berichterstattung wird hervorgehoben, dass OpenClaw-Fähigkeiten mit erheblichem Zugriff wirken können und keine harmlosen Metadaten sind. (The Verge)

Verabschiedung eines formellen Verfahrens:

• Zulassungsliste anerkannte Fähigkeiten
• eine Überprüfung des Codes für neue Fähigkeiten verlangen
• intern geprüfte Fähigkeiten widerspiegeln
• direkte Installationen von öffentlichen Registern auf Unternehmensendgeräten blockieren
• Einrichtungsanweisungen und Dokumente zu prüfen, nicht nur Codedateien
• Überwachung des Prozesses/Netzwerkverhaltens nach der Installation

Priorität 5: Behandlung von Protokollen als nicht vertrauenswürdige Eingabe in KI-Workflows

Das Advisory von GitHub ist eindeutig: Wenn Protokolle später von einem LLM gelesen/interpretiert werden, können manipulierte Werte in Protokollen das Risiko einer indirekten Prompt Injection erhöhen. Zu den Abhilfemaßnahmen gehören die Bereinigung/Escaping und die Nicht-Ausführung von Anweisungen, die von Protokollen abgeleitet sind. (GitHub)

Dies gilt nicht nur für OpenClaw. Jede KI-gestützte Debugging-Pipeline sollte:

• Protokollinhalte bereinigen
• Beibehaltung von Herkunftskennzeichnungen (nicht vertrauenswürdig vs. systemgeneriert)
• die Ausführung direkter Maßnahmen durch Modellvorschläge verhindern
• eine menschliche Genehmigung für Befehle erfordern
• Vermeidung der Einspeisung von Rohprotokollen in privilegierte Automatisierungen

Verifizierung ist wichtiger als Patch-Hinweise

Einer der größten operativen Fehler bei der aktuellen OpenClaw-Welle besteht darin, dass die Behebung als Dokumentationsübung ("wir haben ein Upgrade durchgeführt") und nicht als Verifizierungsübung ("wir haben bewiesen, dass das riskante Verhalten aufgehört hat") behandelt wird.

Sicherheitsteams sollten die Abhilfemaßnahmen auf vier Ebenen validieren:

1) Validierung der Version

Bestätigen Sie die Laufzeitversion, nicht nur die Ausgabe des Paketmanagers.

2) Netzwerk-Validierung

Prüfen Sie, ob die Steuerebene nicht von außen erreichbar ist.

3) Validierung des Verhaltens

Testen Sie, ob zuvor risikobehaftete Abläufe (z. B. Header-Logging-Verhalten, Konfigurationsschreibvorgänge, Erreichbarkeit von Endpunkten) tatsächlich entschärft werden.

4) Geheime Hygienevalidierung

Die Bestätigungsschlüssel wurden gedreht und die alten Ausweise funktionieren nicht mehr.

Beispiel für ein defensives Validierungsskript (kein Exploit, nur Sicherheitsüberprüfungen)

#!/usr/bin/env python3
"""
OpenClaw defensive Validierungshilfe (nur sichere Prüfungen)
- Überprüft die Annahmen zur Erreichbarkeit des lokalen Gateways
- Überprüft Antwort-Header und grundlegende Endpunkt-Exposition
- Nutzt KEINE Sicherheitslücken aus
"""

Socket importieren
importiere Anfragen
from urllib.parse import urljoin

TARGETS = [
    ("127.0.0.1", 18789),
    ("localhost", 18789),
]

def is_port_open(host, port, timeout=1.0):
    s = socket.socket()
    s.settimeout(timeout)
    try:
        s.connect((host, port))
        return True
    außer Exception:
        return False
    finally:
        s.close()

def check_http(base_url):
    results = []
    for path in ["/", "/health", "/api/version"]:
        url = urljoin(base_url, path)
        try:
            r = requests.get(url, timeout=2)
            results.append((path, r.status_code, dict(r.headers)))
        except Exception as e:
            results.append((path, "ERR", str(e)))
    return results

def main():
    print("=== OpenClaw Defensive Validation (safe) ===")
    for host, port in TARGETS:
        open_ = is_port_open(host, port)
        print(f"[+] {host}:{port} open={open_}")
        if open_:
            base = f "http://{host}:{port}"
            for item in check_http(base):
                print(" ", item)

if __name__ == "__main__":
    main()

Diese Art von Skript wird Ihnen nicht alles sagen. Es hilft Teams jedoch, den häufigen Fehler zu vermeiden, davon auszugehen, dass ein Patch angewendet wurde, wenn der anfällige Dienst noch in einem alten Prozess, Container oder einer alternativen Portbindung läuft.

Was Sicherheitsteams in Unternehmen diese Woche tun sollten

Wenn OpenClaw in Ihrer Umgebung vorhanden ist (einschließlich Schatten-IT/persönliche Geräte, die mit Unternehmensdiensten verbunden sind), ist die richtige Reaktion keine Panik. Sie besteht in einem gezielten, auf Beweise gestützten Eindämmungs- und Abhärtungsprogramm.

Tabelle: 7-Tage-OpenClaw-Sicherheitsreaktionsplan

Tag	Ziel	Aktionen	Zu sammelnde Nachweise
1	Verwendung entdecken	Bestandsaufnahme, EDR-Suche, Netzwerk-Scans nach gängigen Ports/Prozessnamen	Gastgeberliste, Eigentümerliste
2	Exposition reduzieren	Internetzugang entfernen, nur VPN-Administrator-Zugang, Proxy-Kontrollen	Vorher/Nachher-Erreichbarkeitstests
3	Aufnäher	Aktualisieren auf korrigierte Versionen, Neustart der Dienste	Laufzeitversionsnachweis, Einsatzprotokolle
4	Geheimnisse	API-Schlüssel/Tokens rotieren, alte Zugangsdaten widerrufen	Zeitstempel der Rotation, Nutzungsprotokolle
5	Fertigkeiten	Inventarisierung der installierten Fertigkeiten/Erweiterungen, Entfernen nicht vertrauenswürdiger Fertigkeiten	Skill Inventory Diff
6	Überwachung	Hinzufügen von Erkennungen für untergeordnete Agentenprozesse/ausgehende Bursts	SIEM-Warnungen, Baselines
7	Politik	Definition der genehmigten Verwendung, des Berechtigungsmodells und des Verfahrens zur Überprüfung der Fähigkeiten	Politikdokument + Ausnahmen

Diese Art von Reaktionsplan lässt sich besser skalieren als der Versuch, jeder Schlagzeile einzeln nachzugehen.

Wie dies mit der breiteren KI-Agentensicherheit im Jahr 2026 zusammenhängt

OpenClaw ist nicht die letzte Agentenplattform, die mit dieser Art von Sicherheitskrise konfrontiert ist. Sie ist einfach die erste, die groß und schnell genug ist, um das Muster sichtbar zu machen.

Die wichtigste Lehre ist, dass KI-Agenten bringen bisher getrennte Vertrauensbereiche zusammen:

• Benutzerabsicht
• ausführbare Automatisierung
• geheime Lagerung
• externe Plugins/Fähigkeiten
• Protokolle und Debugging-Pipelines
• Chat-gesteuerte Bedienelemente

Wenn diese Bereiche in einem Prozess zusammenlaufen, werden alte Annahmen hinfällig:

• "Es ist nur eine lokale App".
• "Es ist nur ein Browser-Tool"
• "Es ist nur eine Logmeldung"
• "Es ist nur eine Abschlagsfähigkeit"
• "Es ist nur ein API-Schlüssel".

Die jüngsten Hinweise und Berichte von OpenClaw machen dies auf eine Art und Weise sichtbar, wie es die Standardbeispiele für Web-Apps nicht tun. (GitHub)

Wenn Ihr Team überlegt, wie es die Abwehr von KI-Agenten operationalisieren kann, ist OpenClaw ein guter Anwendungsfall für kontinuierliche Verifikation statt einmaliger Kontrollen.

Eine Plattform wie Sträflich kann nützlich sein, wenn Teams damit Schwierigkeiten haben:

• Wiederholtes Testen der Exposition des Wirkstoffs auf der Kontrollebene
• Validierung der Wirksamkeit von Patches nach Upgrades
• Überprüfung risikoreicher Konfigurationen über viele Hosts hinweg
• Automatisierung der Beweiserhebung für die Überprüfung von Sanierungsmaßnahmen
• Aufrechterhaltung sicherer, wiederholbarer Testabläufe ohne Ad-hoc-Skripte

Dies ist besonders wichtig, wenn das Risiko nicht ein einzelnes CVE ist, sondern eine Kette von Bedingungen (Exposition + Privileg + unsichere Erweiterung + schwache Überwachung). Der Wert liegt weniger darin, "einen Fehler zu finden", sondern eher darin, zu beweisen, ob die Umgebung nach betrieblichen Änderungen noch anfällig ist.

Penligent hat auch mehrere OpenClaw-bezogene Analysen veröffentlicht, die als Kontext für Sicherheitsteams dienen können, die interne Anleitungen und Schulungen zu agentenbezogenen Risikomustern erstellen, einschließlich Log-Poisoning/indirekte Prompt-Injection und Skills Ecosystem Poisoning. (Sträflich)

Schlussfolgerung

Die jüngsten Berichte über mehrere Hackergruppen, die OpenClaw-Instanzen ausnutzen, um API-Schlüssel zu stehlen und Malware einzusetzen, sind keine isolierte Anomalie. Sie sind das erwartete Ergebnis einer Plattformklasse, die hohe Privilegien, schnelle Akzeptanz, erweiterte Ökosysteme und sich entwickelnde Sicherheitsgrenzen kombiniert. (Nachrichten zur Cybersicherheit)

Die richtige Reaktion ist nicht, KI-Agenten für "von Natur aus unsicher" zu erklären oder die Vorfälle als Benutzerfehler abzutun. Die richtige Antwort ist die Weiterentwicklung des Betriebsmodells:

• Belichtung reduzieren
• schnell flicken
• Verhalten überprüfen
• Privilegien minimieren
• Fähigkeiten als ausführbaren Code behandeln
• Protokolle als nicht vertrauenswürdige Eingabe behandeln
• Überwachung von Agentenaktionen als Sicherheitssignal erster Klasse

OpenClaw zwingt die Branche dazu, diese Lektionen frühzeitig zu lernen. Teams, die sie jetzt lernen, werden viel besser auf die nächste Generation von Agententools vorbereitet sein - egal, ob sie OpenClaw oder anders heißen.

Referenzen

• NVD: CVE-2026-25253 (OpenClaw / Clawdbot / Moltbot Token-bezogenen Gateway Problem) (NVD)
• NVD: CVE-2026-25593 (lokale WebSocket-Konfiguration schreiben → Befehlsinjektion als Gateway-Benutzer) (NVD)
• GitHub Advisory Datenbank: GHSA-g27f-9qjv-22pm (OpenClaw-Protokollvergiftung / indirekte Eingabeaufforderung über WebSocket-Header) (GitHub)
• GitHub OpenClaw Security Advisories (fortlaufender Beratungsstrom) (GitHub)
• Eye Security-Forschung zu OpenClaw Log Poisoning und Patch-Kontext (Augenforschung)
• Hunt.io Expositionsanalyse für OpenClaw-Instanzen mit Internetanschluss und CVE-2026-25253-Kontext (jagen.io)
• Cyber Security News: Mehrere Hackergruppen nutzen OpenClaw-Instanzen aus, um API-Schlüssel zu stehlen und Malware zu installieren (Nachrichten zur Cybersicherheit)
• The Verge: OpenClaw-Fähigkeiten Ökosystem Malware-Risiken und Angriffsfläche Implikationen (The Verge)
• Tom's Hardware: bösartige ClawHub-Fähigkeiten, das Verhalten von ausführbaren Erweiterungen und Social-Engineering-Einrichtungsabläufe (Toms Hardware)
• OpenClaw Log Poisoning / indirekte Prompt Injection Artikel (behoben in 2026.2.13) (Sträflich)
• Vergiftung durch OpenClaw-Fähigkeiten / "SKILL.md wird ein Installateur" Analyse (Sträflich)
• OpenClaw Sicherheitsmanifest / Leitfaden zur architektonischen Härtung (Sträflich)
• OpenClaw zero-click RCE und indirekte Injektion (historischer Kontext / interne Schulung) (Sträflich)