OpenClaw Agent: Fake VS Code Extension und die neue Angriffsfläche agentischer Assistenten

Was ist OpenClaw (ehemals Clawdbot/Moltbot)?

OpenClaw steht exemplarisch für eine neue Klasse von KI-Systemen: „agentische Assistenten“. Der Unterschied zu klassischen Chatbots ist nicht die Gesprächsqualität, sondern die Fähigkeit, Aktionen auszuführen. Statt nur Antworten zu generieren, können Agenten Tools ansteuern, Integrationen nutzen und damit reale Nebenwirkungen erzeugen (z. B. Kalenderaktionen, E-Mails, Dateioperationen, API-Calls).

Typischer Aufbau solcher Systeme:

• Ein lokaler oder selbst gehosteter „Gateway“-Dienst als Control-Plane (Sitzungen, Tool-Aufrufe, Events).
• Eine Control UI, die Konfiguration, Verbindungen und Ausführungen steuert.
• Erweiterbarkeit über Skills/Plugins/Integrationen (Ökosystem-Effekt).
• Ein oder mehrere „Eingangskanäle“ (z. B. Messaging, Web, E-Mail), über die untrusted Input in den Agent-Kontext gelangt.

Der Sicherheitsknackpunkt entsteht genau dort: Untrusted Input (Nachrichten, Links, Doku-Snippets) trifft auf Systeme mit Tool-Rechten und Tokens.

Was ist vorgefallen

1) Fake VS Code Extension „ClawdBot Agent“ (Supply-Chain/Impersonation)

Im Umfeld des Projekts ist eine Extension im VS-Code-Ökosystem aufgetaucht, die sich als „ClawdBot Agent“ bzw. als offizieller Coding-Assistant ausgab, tatsächlich aber Malware-Verhalten zeigte (Tarnung als funktionierende Extension, im Hintergrund Nachladen/Dropper-Verhalten).

Warum das wichtig ist:

• Entwicklungsumgebungen sind hochprivilegierte Arbeitsplätze: Editor, Shell, Tokens, SSH-Keys, Cloud-Credentials.
• Eine kompromittierte Extension ist praktisch ein „Initial Access“ ohne Umweg über Produktionssysteme.
• Der Vektor ist weniger „Exploit“, mehr „Vertrauen“ (Imitation, Naming, Branding, Erwartungshaltung durch Hype).

2) Kritische 1-Click-RCE: CVE-2026-25253 (Control-UI/Gateway-Token-Kontext)

Für OpenClaw wurde eine Schwachstelle unter CVE-2026-25253 öffentlich, die in der Praxis auf ein gefährliches Muster hinausläuft:

• Die Control UI übernimmt ein Gateway-Ziel aus einem URL-Parameter.
• Beim Öffnen der UI wird automatisch eine Verbindung aufgebaut.
• Dabei wird ein gespeichertes Token in Richtung des (potenziell fremden) Gateways gesendet.

Das ist deshalb kritisch, weil „ein Klick auf einen Link“ ausreichen kann, um den Token-Kontext zu kompromittieren. Sobald Tokens entwendet sind, sind Folgeeffekte möglich: unautorisierte Gateway-Steuerung, Tool-Aufrufe, und in manchen Konfigurationen bis hin zur Code-Ausführung über die Kette „Gateway kompromittiert → Agent führt aus“.

Wichtige Implikation: Control-UIs sind keine „harmlosen UIs“. Sie sind Sicherheitsgrenze.

3) Malware über Skills/Plugins (Ökosystem-Risiko)

Parallel wurde eine Welle von bösartigen Skills/Plugins beschrieben, die nicht zwingend über technische Exploits wirkt, sondern über Social Engineering:

• Skills wirken legitim, mit überzeugender Dokumentation.
• Installation/Prerequisites führen Nutzer zu riskanten Handlungen (z. B. fremde Binaries/Skripte ausführen).
• Ziel ist häufig Credential-/Key-Diebstahl (API-Keys, Wallet-Secrets, Tokens) und Persistenz auf dem Host.

Das Muster ist aus klassischen „Plugin Stores“ bekannt, trifft Agenten aber härter: Agenten sind genau dafür gebaut, sich tief zu integrieren und „mehr zu dürfen“.

Warum das mehr ist als ein Einzelfall

Diese drei Ereignisse zeigen dasselbe Grundproblem aus verschiedenen Blickwinkeln:

• Agenten verknüpfen untrusted Input mit privilegierten Aktionen.
• Ökosysteme (Extensions, Skills, Registries) wachsen schneller als Trust-Mechanismen (Signaturen, Reviews, Sandboxing).
• Naming/Rebrands und virale Verbreitung erzeugen ideale Bedingungen für Imitation, Typosquatting und Marketplace-Missbrauch.
• Die „schnelle Produktivität“ (Auto-Connect, Convenience-UX, Copy/Paste-Install) kollidiert mit Sicherheitsrealität.

Wichtige Punkte zum Mitnehmen

A) Definiere den Agent als Automations-Endpoint, nicht als Chatbot

Sicherheits- und Betriebsprozesse sollten so denken:

• Ein Agent ist ein System, das Aktionen ausführt.
• Jede Aktion braucht ein Recht (Scope) und einen Audit-Trail.
• Jeder Eingangskanal ist untrusted input.

B) Reduziere die Exposition von Gateway und Control UI

Minimum-Baseline:

• Control UI niemals „einfach öffentlich“ erreichbar machen.
• Zugriff über VPN/Zero-Trust-Access, starke Authentisierung, idealerweise zusätzliche Netzwerkbarrieren.
• Keine Links/Deep-Links in Tickets/Chats, die Parametrisierung von Zielsystemen oder Auto-Connect begünstigen.

C) Supply-Chain-Regeln für Extensions und Skills einführen

Wenn Agenten oder Entwickler-Tools betroffen sind, sollten die gleichen Prinzipien gelten wie bei Dependencies:

• Allowlist statt „frei installierbar“.
• Herkunft prüfen (Publisher, Repo, Release-Prozess).
• Updates pinnen/steuern; keine Auto-Updates ohne Change-Transparenz.
• Copy/Paste-Anleitungen aus Dokus grundsätzlich als Risikoindikator behandeln.

D) Secrets und Tokens als „Exploit-Beschleuniger“ verstehen

Viele Agenten-Angriffe zielen nicht auf RCE, sondern auf Tokens:

• Scopes minimal halten (Least Privilege).
• Tokens kurzlebig (TTL), rotierbar, getrennt nach Umgebung (Experiment/Pilot/Prod).
• Keine „All-in-one“-Tokens, die Mail/Calendar/Git/Cloud in einem Credential bündeln.

E) Observability ist keine Komfortfunktion, sondern Kontrolle

Pflicht, nicht Kür:

• Action-Log: welcher Input → welcher Tool-Call → welches Ergebnis.
• Netzwerk-Logs/Egress-Transparenz: welche Domains werden kontaktiert.
• Kill-Switch: Tools/Integrationen sofort deaktivierbar, Tokens rotierbar, Host isolierbar.

Minimaler Maßnahmenplan

1. Inventarisieren: Wo laufen Agenten? Welche Versionen? Welche Integrationen? Welche Skills/Extensions?
2. Patch-Status prüfen: Falls OpenClaw im Einsatz ist, sicherstellen, dass bekannte kritische Versionen nicht mehr laufen.
3. Zugang absichern: Control UI/Gateway nur über abgesicherte Pfade, keine öffentliche Exposure.
4. Policies setzen: DM-/Gruppen-Activation kontrollieren (Allowlists, Mentions, Rate Limits).
5. Skill-/Extension-Policy: Allowlist, Review-Prozess, Update-Kontrolle, Removal-Prozess.
6. Secrets reduzieren: Scopes klein, TTL kurz, Rotation planbar, getrennte Konten/Service Principals.
7. Logging aktivieren: Audit-Trail für Tool-Invocations und Konfigurationsänderungen.
8. Incident-Runbook erstellen: Isolation, Rotation, Re-Image, Forensik (Logs sichern).

Fazit

Wenn du agentische Assistenten (OpenClaw oder vergleichbare Systeme) evaluierst, starte nicht mit Features, sondern mit einem sauberen Betriebsmodell: separierte Environments, klare Rechte, kontrollierte Erweiterungen, vollständiges Logging und ein Kill-Switch. Genau damit trennst du „spannende Demo“ von „verantwortbarer Produktivnutzung“.