Schlagwort: RCE

KI/ML, Malware, Schwachstelle, Supply Chain

OpenClaw: Die Real‑World‑Bestätigung der MCP‑Risikoachsen

TL;DR: In meinem Beitrag „Die dunkle Seite des Model Context Protocols (MCP)“ habe ich vier Risikoachsen beschrieben: Tool Poisoning, Prompt Injection, Sampling Abuse/Autonomie, Composability und Chaining. Die jüngsten Vorfälle rund um OpenClaw zeigen diese Risiken in der Praxis: hunderte bösartige Skills in ClawHub, eine 1‑Klick‑RCE‑Schwachstelle (CVE‑2026‑25253), zehntausende fehlkonfigurierte, öffentlich erreichbare Instanzen sowie ein rasantes Wachstum eines offenen Ökosystems, das Produktivität und Missbrauch gleichermaßen skaliert.

Was ist OpenClaw?

OpenClaw ist ein selbst gehostetes KI-Agent-Framework (umgangssprachlich “Gateway” genannt) für agentische KI. Es verknüpft Chat‑Kanäle (u. a. WhatsApp, Telegram, Slack/Discord, iMessage) mit „händischen“ Fähigkeiten (vom Ausführen von Shell‑Befehlen und Dateizugriff über Browser‑Automatisierung, bis zu E‑Mail‑Handling) und lässt sich per Web‑UI und CLI steuern. Es läuft lokal (oder im eigenen Server/Container), kann verschiedene Modelle ansprechen und ist über Plugins/Skills erweiterbar.

Das Projekt startete auf GitHub am 24.11.2025 und die Popularität explodierte Ende Januar 2026. Die Bewertung des GitHub‑Repositorys erreichte binnen Wochen die Marke von 150.000 Stars (Stand: 11.02.2026 > 180.000), begleitet von rasantem Ökosystem‑Wachstum rund um den Skill‑Marktplatz ClawHub.

Anmerkungen zur Begrifflichkeit von Skills, Plugins und Tools

Die aktuelle KI‑Agenten‑Landschaft verwendet die Begriffe Skills, Plugins und Tools uneinheitlich und häufig synonym, obwohl sie technisch unterschiedliche Rollen einnehmen können. Ein Skill ist eine konkrete, installierbare Fähigkeit; ein Plugin ist das Erweiterungsmodul, das diese Fähigkeit bereitstellt; ein Tool ist die standardisierte technische Schnittstelle, über die ein Agent solche Fähigkeiten aufruft. Jeder Skill ist in der Regel ein Plugin. Jedes Plugin stellt ein oder mehrere Tools bereit.

Aktueller Missbrauch: Von „ClawHavoc“ bis 1‑Klick‑RCE

Supply‑Chain-Angriffe über Skills

Koi Security hat in einem vollständigen ClawHub‑Audit 341 (von 2.857) bösartige bzw. unsichere Skills identifiziert, die teils als Krypto‑Tools, YouTube‑Utilities oder Typosquats (Tippfehler‑Ausnutzung) getarnt sind. Die Kampagne „ClawHavoc“ setzt u. a. auf passwortgeschützte ZIPs und Base64‑Skripte (glot.io) zur Stager‑Ausführung, mit Payloads wie Atomic macOS Stealer (AMOS) und Keyloggern. SC‑Medien und THN bestätigen die Befunde.

1‑Klick‑RCE (CVE‑2026‑25253)

Ein Kopplungsfehler zwischen User Interface und Gateway erlaubte Token‑Exfiltration via Cross‑Site WebSocket Hijacking. Der Besuch eines präparierten Links genügte, um Konfigurationen zu ändern und Befehle auszuführen („1‑Klick‑RCE“). Der Fix erfolgte am 30. Januar in v2026.1.29. Detaillierte technische Beschreibungen und die in der NVD‑Notiz aufgeführten Links erläutern den Exploit‑Pfad.

Fehlkonfigurationen & Exponierung

Internetweite Scans fanden über 21. 000 öffentlich erreichbare OpenClaw‑Instanzen, teils ohne hinreichende Absicherung. Ursache sind u. a. falsches Binding/Reverse‑Proxy‑Setups und Shadow‑Deployments.1

Gegenmaßnahmen im Ökosystem

Als Reaktion darauf integriert OpenClaw den Dienst VirusTotal Code Insight in den ClawHub, in das Skill-/Plugin-Verzeichnis ClawHub. Beim Upload von Skills wird automatisch ein Hash aus den hochgeladenen Dateien erzeugt, abgeglichen und bei Bedarf gescannt. Zusätzlich werden die Skills täglich neu gescannt, um neu gefundene Schwachstellen abzuwehren. Das reduziert Supply‑Chain‑Risiken, ist aber keine Abwehr gegen Prompt‑Injection oder logisch verpackte „Payload‑Prompts“.

Betrachtung durch die MCP‑Linse: Vier Risikoachsen, live am Beispiel OpenClaw

  • Tool Poisoning: Veröffentlichte Skills/Plugins werden zum Distributionskanal für Stealer, Backdoors oder „Install‑Anleitungen“ mit verschleierten Stagern. ClawHavoc zeigt, wie „wiederverwendbare Verknüpfungen“ einer offenen Plattform zur Lieferkette für Malware werden.
    (LLM03 Supply Chain, LLM04 Data & Model Poisoning)
  • Prompt Injection (auch indirekt): Agenten, die E‑Mails, Webseiten oder Docs lesen, lassen sich über eingebettete Instruktionen manipulieren, inkl. Secret‑Leakage oder gefährlicher Tool‑Aufrufe.
    (LLM01 – Prompt Injection, LLM07 – System Prompt Leakage)
  • Sampling Abuse/Autonomie: Wiederkehrende Automationen (Cron/Jobs, Heartbeats) können stille Kostenlawinen und unbeaufsichtigte Aktionen auslösen; Medienberichte dokumentieren Fehlkonfigurationen mit erheblichen API‑Token‑Kosten.
    (LLM06 Excessive Agency, LLM10 Unbounded Consumption)
  • Composability & Chaining: Mehrstufige Install‑Workflows (Markdown‑Schritte → externer Downloader → Umgehung von Quarantänen) schaffen schwer überschaubare Wirkungsketten, ähnlich klassischen Kill‑Chains, nur in Agenten‑Ökosystemen.
    (LLM06 Excessive Agency, LLM05 Improper Output Handling, LLM03 Supply Chain)

Standardisierung als Hebel

Was MCP als „USB‑C für Agenten“ standardisiert (Tools/Ressourcen/Prompts/Sampling), skaliert auch die Angriffsfläche. Meine ursprüngliche MCP‑Analyse skizzierte genau diese Trade‑Offs.

Empfehlungen

Grundsätzlich sollte OpenClaw niemals auf produktiven Endpunkten betrieben werden. Wenn OpenClaw dennoch eingesetzt werden soll, dann sollte es auf Basis der drei ineinandergreifenden Leitplanken gehärtet werden:

  1. Sandbox (in welcher Umgebung laufen die Tools/Skills)
  2. Tool-Policy (welche Skills darf der Agent überhaupt aufrufen)
  3. Elevated (enger, protokollierter Notausstieg für Host‑Exec‑Befehle)

Aber auch eine konsequente Skill- bzw. Tool-Hygiene muss gewahrt bleiben.

Aus Sicht der MCP‑Linse ergeben sich dann folgende Punkte:

  1. Isolieren & nur lokal binden
    • Sandbox konsequent aktivieren und „dicht“ konfigurieren.
    • Betrieb in VM/Container, ohne Produktions‑Secrets; Gateway ausschließlich auf 127.0.0.1 binden. Für Remote‑Zugriff Tunnel mit starker Authentisierung wie bei SSH oder WireGuard, statt Public Ports und Weiterleitungen verwenden (wie es auch der Hersteller empfiehlt).Datei‑/Workspace‑Zugriff minimieren.
    • Eingebaute Security Audit Funktion regelmäßig ausführen und Befunde beheben.
  2. Patch‑Stand des Gateways erzwingen (Empfehlungsstand: 10.02.2026)
    • Mindestens v2026.1.29 (Fix für CVE‑2026‑25253),
      idealerweise neuere v2026.2‑Releases.
    • Nach der Installation Token rotieren und Logs auf verdächtige WebSocket‑Ereignisse prüfen.
  3. Skill‑Hygiene (Default‑Deny)
    • ClawHub‑Skills sowie deren Updates standardmäßig blocken und nur kuratiert/signiert zulassen
    • Skill‑Bundles vor Installation (Virus Total Code Insight, Sandbox) prüfen.
    • Vorsicht: Virus Total erfasst keine Prompt‑Injection‑Payloads.
    • Policy‑Tipp: Verbieten Sie Markdown‑„Install‑Schritte“ (harmlos wirkende Copy&Paste Anleitungen, die dann schadhafte Befehle z. B. in Base64‑Skripte oder passwortgeschützte ZIPs verstecken) organisatorisch und technisch. Die ClawHavoc‑Kette nutzte exakt solche Muster.
  4. EDR & Netzwerk‑Kontrollen
    • Detektion für Shell‑Aufrufe aus Gateway/Agent heraus, Least‑Privilege‑Policies für Tools (exec/fs nur bei Bedarf) und DPI/Netzwerkregeln gegen verdächtige Fetch‑Muster (z. B. glot.io‑Snippets, atypische GitHub‑Fetches).
    • Enterprise‑Sicht: Sichtbarkeit und Laufzeitschutz für Agenten, u. a. Erkennen von OpenClaw‑Nutzung, Filterung von Zugriffen aus dem Internet (einschließlich Tunnel- und VPN-Nutzung) und Filterung gegen Prompt‑Injection vor Aktionsausführung.
  5. Kosten‑/Autonomie‑Guardrails
    • Harte Token‑Budgets (analog zu Prepaid-Handyverträgen), Rate‑Limits und Freigabe‑Workflows für periodische Tasks. Autonomie/Sampling nur nach expliziter Freigabe, mit Telemetrie/Alarmierung bei Überschreitung von explizit vorab gesetzten Budgetgrenzen.
  6. Governance (MCP‑Leitplanken übertragen)
    • Leicht verständliche Freigabe‑Workflows und -Oberflächen, explizite Tool‑Freigaben, Kompositionsbarrieren, Logging aus dem MCP‑Kontext 1:1 auf OpenClaw oder ähnliche Frameworks übertragen. Die Risikoachsen sind identisch.
  7. Weitere Quellen:

Einordnung: Von Hype zu Härtung

OpenClaw hat gezeigt, wie schnell agentische KI vom Produktivitäts‑Booster zur Supply‑Chain‑Angriffsfläche werden kann: standardisierte Tool‑Zugriffe + Autonomie + offene Marktplätze eröffnen neue Initial‑Access‑Pfade auf Endpunkte und in Netze. Wer Agenten einsetzen will, braucht eine gewissenhafte Prüfung statt Hype, einschließlich betrieblicher Disziplin (Isolierung, Patchen, Kuratieren), technischer Härtung (Audit, Tool‑Least‑Privilege) und organisatorischer Governance.

Für eine umfassende Sicherheitsbetrachtung von OpenClaw über die MCP-Perspektive hinaus lohnt sich zudem ein Blick auf den bald ebenfalls hier im Blog erscheinenden Beitrag von Volker Tanger.

  1. Shadow‑Deployments testen neue Softwareversionen im Hintergrund mit realem Traffic, ohne dass ein Nutzer etwas mitbekommt. Damit kann Performance, Fehler und Verhalten unter Realbedingungen beobachten werden. ↩︎

Advisories, Log4Shell

Log4Shell-Schwachstelle in Log4j: Überblick

Hilfe zur Selbsthilfe

Unsere aktuelle HiSolutions „Hilfe zur Selbsthilfe Log4Shell“ (v1.11 vom 05.01.2022 07:00) gibt es hier zum Download:

(Danke an das Team für die schnelle Arbeit – Inés Atug, Markus Drenger, Enno Ewers, Daniel Jedecke, Lisa Lobmeyer, Lena Morgenroth, Folker Schmidt, Volker Tanger, Manuel Atug.)

HiSolutions-Selbsthilfe-log4j_version-1.11Herunterladen

Go to English version

Changelog 

V1.11 (05.01.2022 07:00): CVE-2021-44832 (Arbitrary Code Execution) und Updatehinweis auf Version 2.17.1 ergänzt. Hinweis auf Ausnutzung ohne Nachladen von Schadcode entfernt. Scantools von AV-, Endpoint-Protection-, IDS- und Schwachstellenscanner-Herstellern ergänzt. Bekannte Angriffe ergänzt.

V1.10 (22.12.2021 09:00): Abgleich mit dem erweiterten BSI-Dokument (Stand 20.12.2021). Ergänzen der Gefährdungslage. Überarbeitung der Dokumentenstruktur. Löschung von Dopplungen. Ergänzen von Maßnahmenempfehlungen. Ergänzen bisher bekannter Angriffe (zum Ableiten möglicher IOCs).

V1.9 (20.12.2021 21:00): Expliziter Hinweis, dass generell alle Versionen vor 2.17.0 anfällig sind. Hinweis auf neue Schwachstelle in Version 2.16.0. Hinweis auf Prüfung in ICS-Umgebungen. Einbeziehung von Produkt-Herstellern und Dienstleistern konkretisiert.

V1.8 (15.12.2021 20:00): Verbesserung und Hinweise zu Überprüfung von Linux-Systemen per Kommandozeile.

V1.7 (15.12.2021 18:00): Verweis auf Angriffe mittels Ransomware hinzugefügt. Klarstellung zur Zielgruppe des Dokumentes eingefügt. Sprachliche Verbesserungen. Hinweis auf besseres Logging eingebaut. Hinweis auf CI/CD und Wiederherstellung von Backups eingefügt.

V1.6 (15.12.2021 12:00): CISA-Liste betroffener Produkte hinzugefügt. Hervorhebung der neuen Log4j 2.15.0 CVE-2021-45046 und des Defizits im ersten Patch. Prüfung via Konsole auf Linux-Systemen. Strukturiertes Vorgehen, um zu erkennen, ob Angreifer sich eingenistet und im Anschluss selber das System gepatcht haben. Verifikation der Behebung der Verwundbarkeit nach Patch. Datenschutzrelevantes Dokument vom BayLDA aufgenommen. BSI-Dokumente referenziert. Hinweis auf Feedbackmöglichkeit.

V1.5 (14.12.2021 15:00): Priorisierung und Liste aller Produkte. Wir haben eine Empfehlung zur Priorisierung hinzugeführt sowie eine Vorgehensweise der strukturierten Erfassung aller Produkte, die betroffen sind, und wie diese abgearbeitet werden kann.

V1.4 (14.12.2021 13:00): log4j v1.x mit CVE-2021-4104 adressiert. Ausnutzung der Schwachstellen seit 1.12.2021. Cloud Dienste hinzugefügt. Potentiell betroffene Systeme mit drei Merkmalen beschrieben. Intranet erläutert. Egress-Filter (ausgehender Datenverkehr) hinzugefügt. Hinweis auf Logfile-Sicherungen aufgrund der Angriffe seit 1.12.2021. Hinweis auf Aussage Hessischer Beauftragter für Datenschutz und Informationsfreiheit (HBDI), dass wegen Art. 33 DSGVO auf erfolgreiche Angriffe zu prüfen ist. 

V1.3 (13.12.2021 17:00): Erste veröffentlichte Version 

Beiträge zu Log4Shell/Log4j

  • Log4Shell: HiSolutions Self-Help Guide Log4j
    The following self-help guide contains HiSolutions‘ expert assessment, recommendations, IT procedures, and measures to cope with the ongoing Log4Shell cybersecurity incident and attack wave caused by a critical vulnerability in the Apache Log4j logging library. Special thanks to Lisa Lobmeyer for the English version.
  • Log4Shell-Schwachstelle in Log4j: Überblick
    Hilfe zur Selbsthilfe Unsere aktuelle HiSolutions „Hilfe zur Selbsthilfe Log4Shell“ (v1.11 vom 05.01.2022 07:00) gibt es hier zum Download: (Danke an das Team für die schnelle Arbeit – Inés Atug, Markus Drenger, Enno Ewers, Daniel Jedecke, Lisa Lobmeyer, Lena Morgenroth, Folker Schmidt, Volker Tanger, Manuel Atug.) Go to English version Changelog  V1.11 (05.01.2022 07:00): CVE-2021-44832 (Arbitrary Code Execution) und Updatehinweis auf Version 2.17.1 ergänzt. Hinweis auf Ausnutzung ohne Nachladen von Schadcode entfernt. Scantools von AV-, Endpoint-Protection-, IDS- und Schwachstellenscanner-Herstellern ergänzt. […]
  • Log4Shell: Massive Bedrohung durch Schwachstelle in Bibliothek Log4j
    Aktuell besteht eine IT-Sicherheitsbedrohung der höchsten Warnstufe: Durch eine Schwachstelle in der weitverbreiteten Java-Protokollierungsbibliothek Log4 sind sehr viele Systeme, Anwendungen und Applikationen (unvollständige, ständig wachsende Liste hier) anfällig für einen sehr einfach durchzuführende Remote Code Execution Angriff (RCE). Ein Vielzahl von Akteuren scannt bereits das Internet nach vulnerablen Instanzen, und erste Angreifer haben bereits begonnen, Backdoors auf Systemen zu installieren. Diese könnten später etwa für Ransomware-Angriffe missbraucht werden. Die Bibliothek ist dringend zu patchen – eine Herausforderung durch die vielen […]
Log4Shell

Log4Shell: Massive Bedrohung durch Schwachstelle in Bibliothek Log4j

Aktuell besteht eine IT-Sicherheitsbedrohung der höchsten Warnstufe: Durch eine Schwachstelle in der weitverbreiteten Java-Protokollierungsbibliothek Log4 sind sehr viele Systeme, Anwendungen und Applikationen (unvollständige, ständig wachsende Liste hier) anfällig für einen sehr einfach durchzuführende Remote Code Execution Angriff (RCE).

Ein Vielzahl von Akteuren scannt bereits das Internet nach vulnerablen Instanzen, und erste Angreifer haben bereits begonnen, Backdoors auf Systemen zu installieren. Diese könnten später etwa für Ransomware-Angriffe missbraucht werden.

Die Bibliothek ist dringend zu patchen – eine Herausforderung durch die vielen Stellen, an denen Log4j zum Einsatz kommt. Häufig sind Anwender auch auf die Zuarbeit der Hersteller angewiesen. Dabei sind beileibe nicht nur direkt aus dem Internet erreichbare Systeme betroffen.

Der IT-Sicherheitsforscher Kevin Beaumont (@gossithedog) pflegt einen Twitter-Thread mit den neusten Entwicklungen und Tipps:

Advisories

Web vulnerabilities are coming to the Desktop – Template Injections lead to RCE in Teamwire

TL;DR (Teamwire users): A vulnerability has been found in Teamwire which can allow malicious users to execute commands on victim’s computers by sending a crafted Teamwire message. Upgrade Teamwire to the newest version as soon as possible to fix this vulnerability.

TL;DR (Technical): Template injections are a common vulnerability in web applications. If a desktop application built on a web engine is vulnerable to template injection, this can result in remote code execution on the client system.

Background

Template injection refers to a class of vulnerabilities that exploit the insecure embedding of user controllable data into template engines like AngularJS. Template engines use template files to define the design of a user interface by inserting special placeholders into a text. The template engine then dynamically replaces the placeholders with data at runtime, referred to as “rendering” the template. Many modern template engines even support carrying out complex computations inside the templates themselves. If an attacker embed one of these placeholders into a template, he can often execute functions in the underlying programming language.

To help support cross-platform compatibility, software vendors started embedding web engines into client desktop applications, thus removing the need to develop native applications for all different client platforms. NW.js is a technology that combines the browser engine WebKit with the JavaScript framework Node.js, and is often used to create cross-platform applications. This combination enables users to call Node.js functions directly from the DOM of the embedded Chromium browser.

For web applications, template injections are well known problem. Due to the increasing use of web technologies for the rapid development of client applications, this class of vulnerabilities has begun to manifest itself on the desktop too.

Teamwire is a “fast, intuitive and secure enterprise messaging app” for businesses. Teamwire clients are available for iPhone, iPad, Android, Windows Phone, Windows PC, Mac OS and Linux.

HiSolutions researchers have found two distinct template injection vulnerabilities during an internal security assessment of the Teamwire messaging platform (clients on Windows and the administrative interface), which could be used to target end users or platform administrators.

Technical Background

Teamwire is built on AngularJS. Angular implements a secure sandbox to attempt to prevent attacks even if user input is insecurely embedded in templates. As the sandbox was repeatedly bypassed, AngularJS developers decided that the effort was futile and shifted the responsibility back to  application developers. Currently, bypasses exist for all AngularJS Versions that enable an attacker to escape from the sandbox and execute arbitrary JavaScript commands.

Template injections in AngularJS can be illustrated as follows: If an attacker succeeds in inserting placeholder string, delineated with double curly brackets ( “{{…}}” ) into a template inside the application, any operations inside the brackets will be carried out when the template is rendered. In this case, inserting {{77*77}} into the name field (left) results in the product (5929) being displayed in the rendered display (right).

The expression „77*77“ evaluates to „5929“ when the template is rendered.

To bypass the sandbox in AngularJS 1.6.8, which is used by Teamwire, the following template string can be used:

{{constructor.constructor(‚###JavaScript-Code-Here###‘)()}}

Vulnerability Details

Stored XXS in Admin Web Interface – CVE-2018-17560

Users can change their displayed usernames in the Teamwire clients without any restrictions. A user could therefore change his username to include a template string:

his {{constructor.constructor(‚document.body.style.backgroundColor = „green“;‘)()}}

Our researchers found that when an administrator views the user inside the administrative web panel, the username is embedded insecurely (i.e. without encoding the placeholder to prevent execution) into the web page and the JavaScript code in the string is executed.

The example payload above only changes the background color of the HTML page, but a malicious user could insert arbitrary JavaScript code to be executed in the browser. An attacker could for example try to take over an administrator’s session or try to execute actions with admin rights in the web portal.

Attempting to delete the “malicious” user also triggers the vulnerability, as the admin must first view the user in the web interface to be able to delete them.

Desktop Client RCE – CVE-2018-17170

Another template injection was found inside the Teamwire desktop client. The vulnerable field was the name of a group chat. A malicious user must first create a chat with a crafted name including the template string. They can exploit this vulnerability to execute code on the victim’s system. If another user included in the chat writes a message to the attacker by selecting him from his contact list, the client merges the chats and the payload is executed on the victim’s system. Because the victim selects the other user from the contact list, he cannot see the manipulated chat name before the JavaScript is executed.

That only the first character of the chat names is displayed in the overview further helps to hide  malicious payloads.


Only the first part of the chat name is shown (left), hiding the malicious part.

The same code execution vulnerability is exploitable when the victim starts a chat with another user with a specially crafted username.

Because the Teamwire desktop client uses NW.js and the embedded Node.js has the ability to spawn arbitrary processes, template injection actually results in remote code execution on the client system.

This example payload opens the windows calculator on the client system:

{{constructor.constructor(„const x=require(‚child_process‘).spawn; x(‚calc.exe‘);“)()}}

The template injection can even lead to code execution on the receiving client.

Due to the internal structure of the code, the payload is executed four times when the vulnerability is triggered by sending a message.

Impact and Mitigations

The impact of the vulnerabilities is limited by the fact that a valid user account attributed to the organization is needed to perform the attack. If an attacker has obtained access to an account, no mitigation against the attack in the web interface (apart from not using it) exist. Preventing the code execution attack against the clients requires not accepting any messages from other accounts, obviating the purpose of a messaging application.

The vulnerabilities described above have been fixed in the backend version prod-2018-11-13-15-00-42  and in the desktop client version 1.9.0 released on 16.11.2018. To fully mitigate the vulnerabilities and continue the use of the product, these updates should be installed as soon as possible.

The vulnerability CVE-2018-17170 has been verified for the desktop client version 1.5.1, it affects most likely all versions prio to 1.9.0. The vulnerability CVE-2018-17560 affects all backend version prior to prod-2018-11-13-15-00-42.

Disclosure Timeline

16. October 2018 – Initial contact with the vendor

16. October 2018 – Submission of vulnerability details to the vendor

22. October 2018 – Further communication with vendor

16. November 2018 – Update released

21.  June 2019 – Public disclosure (the vendor asked for a postponed publication of the details, which we agreed on)

Credits

The vulnerabiliy was found by Julian Beier, Lars Burhop, Benjamin Braun, Viktor Schlüter and Denis Werner (HiSolutions).