OpenClaw: Kritischer RCE und Token-Exfiltration über schädliche Webinhalte

Unternehmen und Produkt

OpenClaw ist ein Open-Source-Framework für die Erstellung und Bereitstellung autonomer KI-Agenten. Diese Agenten können im Web navigieren, Tools ausführen und komplexe, mehrstufige Workflows verwalten. Da es sich in erster Linie um eine selbst gehostete Lösung handelt, wird sie von Unternehmen bevorzugt, die eine lokalisierte Kontrolle über ihre KI-Infrastruktur und den Schutz ihrer Daten benötigen.

Die Stärke der Plattform liegt in ihrer tiefen Integration mit lokalen Dateisystemen, internen APIs und Drittanbieterdiensten. Diese tiefgreifenden Rechte machen OpenClaw-Instanzen jedoch zu einem “begehrten” Ziel für Angreifer, die sich Zugang zu einem Unternehmensnetzwerk oder einer automatisierten Pipeline verschaffen wollen.

Das war passiert

Die Sicherheitslücke entstand durch die fehlende Einhaltung einer klar definierten Vertrauensgrenze zwischen nicht vertrauenswürdigen Webinhalten und der Ausführungsumgebung des Bots.

Versuchte ein OpenClaw-Bot, eine von einem Angreifer kontrollierte Website zu verarbeiten oder zu „durchsuchen“, konnten speziell präparierte Eingaben die vorgesehenen Sanitization-Mechanismen umgehen und die Runtime manipulieren.

Dies hatte drei wesentliche Auswirkungen:

• Remote Code Execution (RCE): Angreifer konnten beliebige Befehle innerhalb der OpenClaw-Runtime ausführen.
• Token-Exfiltration: Sensible Authentifizierungstoken, die vom OpenClaw-Gateway verwendet wurden, wurden an den Angreifer weitergegeben.
• Instanzübernahme: Mit gültigen Tokens und RCE konnten Angreifer die vollständige Kontrolle über die Instanz sowie alle angebundenen nachgelagerten Dienste erlangen.

Der Incident war besonders kritisch, da eine eigentlich standardisierte, automatisierte Aufgabe – das Aufrufen bzw. Verarbeiten einer URL – zu einem direkten Angriffsvektor für eine vollständige Systemkompromittierung wurde.

Timeline

• Incident-Identifizierung: Nach Responsible Disclosure unter der Kennung CVE-2026-25253 erfasst.
• Detection/Eskalation: Bearbeitung im Rahmen eines Responsible-Disclosure-Prozesses; die konkrete TTD (Time to Detect) wurde nicht öffentlich kommuniziert.
• Resolution: Behebung durch einen Security-Patch im Release v2026.1.29.

Zeit bis zur Erkennung (TTD): Nicht bekannt gegeben.

Zeit bis zur Behebung (TTR): Eine korrigierte Version (v2026.1.29) wurde zur Verfügung gestellt; die vollständige Behebung hing davon ab, dass die Nutzer ein Upgrade durchführten und ihre Anmeldedaten änderten.

Wer war betroffen?

Nutzer, die eine selbst gehostete Version von OpenClaw vor v2026.1.29 betrieben, waren gefährdet. Die Risiken waren deutlich höher für:

• Instanzen, die für die Verarbeitung von Inhalten aus nicht vertrauenswürdigen oder öffentlichen Websites konfiguriert waren.
• Bereitstellungen, die Gateways ohne erzwungene TLS- oder Authentifizierung verwendeten.
• Umgebungen, die langlebige API-Schlüssel mit hohen Berechtigungen verwendeten.

Wie reagierte OpenClaw?

OpenClaw hat den Prozess der Responsible Disclosure eingehalten, indem eine gepatchte Version veröffentlicht und ein formelles Security Advisory publiziert wurde. Das Team hat dabei:

• v2026.1.29 mit dem entsprechenden Fix bereitgestellt
  
• ein sofortiges Upgrade auf v2026.2.6 oder höher empfohlen
  
• detaillierte Handlungsempfehlungen zur Credential Rotation und Deployment Hardening veröffentlicht
  
• die Security-Dokumentation um Best Practices zu Netzwerkisolierung, HTTPS und Plugin-Vetting ergänzt
  
  

Dieser Ansatz zielte darauf ab, das Risiko einer breitflächigen Ausnutzung schnell zu minimieren und Betreibern gleichzeitig konkrete Remediation-Schritte an die Hand zu geben.

‍Wie kommunizierte OpenClaw?

Die Kommunikation erfolgte über das offizielle Security Guide and Advisory Portal. Die Botschaften waren direkt und legten mehr Wert auf Transparenz als auf Marketing: Sie definierten klar das RCE-Risiko, listeten die betroffenen Versionen auf und enthielten eine Checkliste für Abhilfemaßnahmen.

Wichtige Learnings für andere Teams

• AI-Ausführung isolieren: KI-Agenten, die externe Daten verarbeiten, müssen in einer gehärteten Sandbox-Umgebung betrieben werden. Nicht vertrauenswürdige Webinhalte dürfen niemals direkten Zugriff auf den Execution Context des Host-Systems erhalten.
• Kurzlebige Credentials einsetzen: Um die Auswirkungen einer möglichen Token-Exfiltration zu minimieren, sollten zeitlich begrenzte und klar gescopte Tokens verwendet werden – keine langlebigen Master-Keys.
• Secure by Default: Self-Hosted-Software muss standardmäßig (out of the box) Authentifizierung und TLS-Verschlüsselung erzwingen, um unbeabsichtigte Offenlegung zu verhindern.
• Vulnerability-Urgency: Sicherheitslücken in Automatisierungs-Tools sind mit derselben operativen Priorität zu behandeln wie ein vollständiger Service-Ausfall.‍

Zusammenfassung

OpenClaw hat eine kritische Schwachstelle (CVE-2026-25253) behoben, die es Angreifern ermöglichte, über schädliche URLs Code auszuführen und Anmeldedaten zu stehlen. Nutzer mussten auf Version 2026.1.29 oder höher aktualisieren, alle API-Schlüssel rotieren und eine Netzwerkisolierung implementieren, um sicher zu bleiben.

So kann ilert unterstützen

Schwerwiegende Schwachstellen wie CVE-2026-25253 erfordern eine schnelle, koordinierte Reaktion über Security, Plattform und IT-Betrieb hinweg. ilert unterstützt Unternehmen dabei, unter hohem Zeitdruck strukturiert und effizient zu handeln:

• Vulnerability Alerting:
  ilert lässt sich in gängige Security-Scanner integrieren und erzeugt automatisch High-Priority-Incidents, sobald kritische CVEs in produktiven Umgebungen erkannt werden. Dadurch werden Security-Teams in Echtzeit alarmiert und können unmittelbar reagieren.
• Confidential Response:
  Mit privaten Incident Rooms ermöglicht ilert eine vertrauliche Abstimmung zu Exploits, Risikoanalysen und Remediation-Maßnahmen – getrennt von allgemeinen Kommunikationskanälen.
• Stakeholder-Kommunikation:
  Die KI-gestützte Incident-Kommunikation unterstützt bei der Erstellung klarer, strukturierter Updates für interne Stakeholder und Statusseiten. So bleibt die Transparenz gewahrt, ohne operative Teams zusätzlich zu belasten.
• On-Call Routing: SEV-1-Security-Alerts werden automatisch an definierte Security-Leads und Infrastrukturverantwortliche eskaliert. Durch gezieltes Routing und Eskalationsregeln wird das Ausnutzungsfenster signifikant verkürzt.