Die jüngsten Einschätzungen von Palo Alto Networks Unit 42 zeigen, wie schnell Angriffe in der Praxis „autonom“ werden können: Ein chinesischsprachiger Bedrohungsakteur soll dabei DeepSeek-Angriffe Telegram genutzt haben, um mit Hilfe des Open-Source-Frameworks Hermes Agent eigenständig Zielsysteme zu prüfen und passende Exploits auszuwählen.
Der Ablauf begann mit einer Eingabe über Telegram. Danach übernahm die Agent-Software mehrere Schritte ohne weitere manuelle Steuerung: Sie suchte nach öffentlich erreichbaren Systemen, bewertete Verwundbarkeiten und führte Exploit-Versuche in mehreren „Spuren“ aus. Die Details verdeutlichen vor allem eines: Schon ein ungewolltes zusätzliches Setup kann Angreifenden in die Karten spielen – und verteidigen sie trotzdem auch weniger eindeutig nachvollziehbar machen.
So lief der Angriff über Telegram und Hermes Agent
Nach den Recherchen von Unit 42 kam der Impuls für die Operation zunächst über Telegram. Der Hermes Agent nutzte anschließend die bereitgestellte Logik, um das Umfeld zu scannen und potenzielle Angriffsziele zu finden.
Besonders relevant ist: In der wiederhergestellten Sitzung fanden die Analysten keine weiteren direkten Eingaben des Operators während des laufenden Vorgehens. Das legt nahe, dass die Agent-Instanz nach dem Start eine Reihe von Aufgaben selbständig abarbeitete.
Währenddessen soll die Software internet-facing Systeme identifiziert und dann auf Basis der gefundenen Bedingungen öffentliche Exploits ausgewählt haben. Unit 42 ordnet diese Vorgehensweise als Kombination aus autonomen und konventionellen Arbeitsabläufen ein.
Warum DeepSeek eine zentrale Rolle spielte
In Hermes Agent fungierte DeepSeek als primäres Modell für die Denk- und Entscheidungslogik. Laut Bericht lieferte es terminalbasierte Zugriffe, wiederverwendbare Fähigkeiten („skills“) und die Unterstützung für unbeaufsichtigte Ausführung.
Darüber hinaus fanden die Forscher nur einen begrenzten Einsatz weiterer Code-Assistants, darunter Claude Code und Qwen Code. In Exploit-Entwicklungsverzeichnissen gab es zudem Hinweise auf „Codex“-Nutzung, allerdings ohne gesicherte Bestätigung, weil die Chat-Protokolle nicht erhalten waren.
Dass Hermes Agent grundsätzlich auch über Telegram arbeiten kann, Befehle ausführt und Aufgaben zeitgesteuert im Hintergrund erledigt, ist laut eigener Dokumentation des Frameworks ebenfalls bestätigt.
Exploit-Auswahl, Zielumfang und fehlende Bestätigung
Unit 42 ordnet sieben unterschiedliche Exploit-Ketten bzw. „Tracks“ in der Operation ein. Dabei kamen insgesamt acht Common Vulnerabilities and Exposures (CVE)-Kennungen zum Einsatz.
Der Grund für die Diskrepanz: In einer n8n-Kette wurden zwei Schwachstellen kombiniert. Die Analyse nennt dabei auch Beispiele, bei denen Angriffe scheiterten – nicht zwingend, weil der Exploit „falsch“ war, sondern weil die Konfiguration der exponierten Systeme nicht zu den Anforderungen passte.
Ein weiteres Detail sticht hervor: Die Angreifer sollen gegen mehr als 460 Ziele Exploit-Versuche gefahren haben. Später berichtet Unit 42 jedoch zugleich, es habe nur drei erfolgreich ausnutzbare Ziele verifizieren können. Der Bericht erklärt diesen Widerspruch nicht vollständig. Nach eigenen Angaben hat The Hacker News bei Palo Alto Networks Rückfrage gehalten und wollte eine Klärung nachreichen.
Langflow und n8n: gescheiterte Versuche trotz Auswahl
Im Bericht werden konkrete Ziele genannt, die im Verlauf der Operation nicht übernommen werden konnten. Bei Langflow und n8n scheiterten die DeepSeek-gesteuerten Angriffe, weil die betroffenen Systeme die notwendigen Konfigurationsbedingungen nicht erfüllten.
Für Langflow wird außerdem eine spätere Versionsprüfung erwähnt: Die Operation stoppte, nachdem das System weder Auto-Login aktiviert hatte noch eine verwertbare öffentliche Flow-ID bereitstellte.
Bei n8n hingegen ging die Kette zwar über zuvor identifizierte Schwachstellen, aber viele Treffer schienen nicht die erforderlichen öffentlichen Formular- oder Endpunktbedingungen zu erfüllen. Damit blieb der Zugriff für diese Ziele aus.
Welche Schwachstellen und Versionen betroffen waren
Unit 42 nennt mehrere CVEs und konkrete Fix-Versionen, die für Administratoren besonders hilfreich sind, um ihre Systeme einzuordnen.
Langflow
- CVE-2026-33017 wurde für Langflow in Version 1.9.0 behoben.
n8n
- CVE-2026-21858 wurde in Version 1.121.0 behoben.
- CVE-2025-68613 wurde in Versionen 1.120.4, 1.121.1 und 1.122.0 behoben.
Damit ergibt sich laut Unit 42: Version 1.121.1 ist die früheste Veröffentlichung, die beide in der Kette genutzten Schwachstellen adressiert.
Marimo
- CVE-2026-39987 wurde für Marimo in Version 0.23.0 behoben.
NetScaler ADC/Gateway (SAML-Setups)
Separat beschreibt Unit 42 außerdem manuelle Operationen, die u. a. eine Datenexfiltration über die NetScaler Memory-Overread-Schwachstelle CVE-2026-3055 sowie Command Execution auf Marimo-Instanzen über CVE-2026-39987 umfassten.
Die Einordnung zu CVE-2026-3055 erfolgt über Citrix: Die Schwachstelle betrifft customer-managed NetScaler ADC und Gateway-Appliances, wenn diese als SAML identity providers konfiguriert sind. Administratoren sollen dafür die Appliance-Konfiguration prüfen (z. B. anhand eines spezifischen SAML-Profil-Musters) und die in der Citrix-Sicherheitsmitteilung aufgeführten Fixes installieren.
Der kritische Fehler: unbeabsichtigter HTTP-Server
Besonders aufschlussreich ist ein technisches Detail, das die Operation gleichzeitig nachvollziehbar und gefährlich macht: Laut Unit 42 startete der Hermes Agent unbeabsichtigt mit python3 -m http.server 8888 aus dem Verzeichnis /home/worker.
Dadurch wurde ein HTTP-Server verfügbar gemacht, der nicht nur harmlose Informationen preisgeben sollte. In der Auswertung wird beschrieben, dass dadurch unter anderem Modellkonfigurationen, API-Keys, Exploit-Skripte, Ziel-Listen, Shell-History sowie Protokolle der autonomen Sitzung zugänglich gewesen sein sollen.
Das zeigt, dass selbst wenn der Angriff „intelligent“ wirkt, kleine Umsetzungspannen im Setup zu erheblichen Sicherheitsrisiken führen können – sowohl für den Angreifer (OpSec) als auch für Verteidiger, die Indizien im Umfeld finden können.
Wie sich die Sitzung im Detail anfühlte
Unit 42 beschreibt eine wiederhergestellte Sitzung aus Mai 2026. Darin soll DeepSeek zunächst einen öffentlichen Exploit für die Code-Injection in Langflow (CVE-2026-33017) heruntergeladen und anschließend mithilfe von FOFA eine erste Auswahl an Instanzen durchgeführt haben.
Im genannten Beispiel wurde ein Ziel gefunden, das eine relevante Langflow-Version ausführte. Der Angriff kam aber nicht weiter, weil die notwendigen Zugangsvoraussetzungen fehlten.
Danach soll die Agent-Instanz weitere Produktfamilien untersucht und auf GitHub nach passenden Proof-of-Concept-Repositories gesucht haben. Anschließend wählte sie n8n aus und kombinierte darin zwei Schwachstellen, darunter die unauthentifizierte Datei-Zugriffsproblematik (CVE-2026-21858) und die Expression-Injection (CVE-2025-68613).
FOFA ergab dabei im Sessionzeitraum laut Bericht sehr viele potenziell passende n8n-Systeme. DeepSeek machte dann schrittweise Sampling, prüfte weitere Kandidaten und identifizierte schließlich nur wenige laufende verwundbare Versionen. Für eine Kompromittierung reichten die öffentlich erreichbaren Form-Endpunkte allerdings häufig nicht aus.
Warum das für Organisationen jetzt wichtig ist
Für Unternehmen liegt die praktische Bedeutung der DeepSeek-Angriffe Telegram-Muster vor allem in zwei Punkten: erstens in der Kombination aus KI-gestützter Entscheidungslogik und automatischem Scannen, zweitens in der Tatsache, dass Angreifer sehr schnell von „Erkennung“ zu „Ausprobieren“ übergehen können.
Unit 42 empfiehlt daher, exponierte Systeme zu patchen – konkret Langflow, n8n und Marimo. Außerdem sollten Organisationen customer-managed NetScaler ADC oder Gateway-Appliances absichern, insbesondere wenn sie als SAML identity providers dienen.
Zusätzlich raten die Analysten, unnötigen öffentlichen Zugang zu Workflow- und Notebook-Schnittstellen zu entfernen. Das reduziert die Angriffsfläche deutlich, selbst wenn ein Agent im Hintergrund Exploit-Logik bereitstellt.
Einordnung des Operators: Indizien, aber keine sichere Identität
Unit 42 ordnet den Operator als in Zhuhai, China ansässig ein. Öffentliche Hinweise passen dazu, sind aber laut Bericht nicht unabhängig verifiziert: So soll ein GitHub-Profil den Namen „KnYuan Knaithe“ zeigen, während ein älterer Blog unter demselben Handle den Autor als „binary security researcher“ in Zhuhai beschreibt.
Diese Spuren belegen jedoch nicht zuverlässig die rechtliche Identität der Person oder eine staatliche Verbindung.
Fazit: Autonome Exploits treffen auf vermeidbare Expositionsfehler
Die Analyse von Unit 42 macht deutlich, wie ein modular aufgebauter Angriffsansatz wie Hermes Agent in Kombination mit einem reasoning-basierten Modell die Hürde zwischen „finden“ und „ausnutzen“ verkürzen kann. Der Start über Telegram war dabei nur der Auslöser; danach liefen Auswahl, Prüfung und Exploit-Versuche weitgehend selbständig.
Für die Verteidigung ist die Botschaft klar: Patchen Sie betroffene Produkte rechtzeitig, überprüfen Sie speziell öffentlich erreichbare Workflow- und Notebook-Schnittstellen und härten Sie SAML-bezogene NetScaler-Konfigurationen ab. So verringern Sie nicht nur bekannte Schwachstellen, sondern auch den Spielraum für autonome Angriffsverläufe.
Quelle: https://thehackernews.com/2026/07/chinese-hacker-commands-deepseek-via.html
