Une campagne de compromission attribuée à un acteur basé en Chine met en lumière une tendance inquiétante : l’usage de modèles d’IA et d’agents d’automatisation capables de mener des actions sans intervention constante. D’après les chercheurs d’Unit 42 (Palo Alto Networks), DeepSeek via Telegram a servi de moteur de décision dans le cadre Hermes Agent, permettant de déclencher et d’orchestrer des attaques contre de nombreuses cibles exposées sur Internet.
Le scénario ne se limite pas à envoyer une commande unique : l’agent sélectionne ensuite des systèmes accessibles, cherche des preuves d’exploitabilité et enchaîne des tentatives d’exploitation selon des critères comme la sévérité et le contexte de déploiement. Résultat : plus de 460 cibles ont été visées avec des workflows autonomes et aussi avec des procédures plus classiques.
Telegram comme point de contrôle de l’agent
Dans le récit technique publié par Unit 42, l’opération démarre par une instruction transmise via Telegram. À partir de là, l’agent s’exécute selon un modèle “autonome” : il explore l’environnement, identifie des services exposés et choisit des exploits publics susceptibles de fonctionner.
Les chercheurs indiquent qu’ils n’ont pas retrouvé de nouvelles instructions de l’opérateur au cours de la session analysée. Autrement dit, une fois la consigne initiale donnée, l’agent a continué à avancer selon sa logique interne.
Hermes Agent et le rôle central de DeepSeek
Le cadre Hermes Agent, décrit comme open source, sert de plateforme d’exécution à l’attaque. Dans ce dispositif, DeepSeek apparaît comme le modèle principal de raisonnement : il fournit l’accès terminal, des “compétences” réutilisables et l’exécution sans surveillance.
Unit 42 a observé un usage plus limité d’autres outils, tels que Claude Code et Qwen Code. Des traces dans des répertoires liés au développement d’exploits laissent aussi penser à une utilisation de Codex, mais les chercheurs précisent qu’ils ne peuvent pas confirmer l’usage effectif, car les journaux de discussion correspondants n’ont pas été conservés.
Le framework lui-même indique, dans sa documentation, qu’il peut fonctionner via Telegram, exécuter des commandes et planifier des tâches non supervisées. Dans ce cas, cette capacité a été exploitée pour enchaîner l’étape de reconnaissance et l’étape d’exploitation.
Plus de 460 cibles : quand l’automatisation accélère la chasse
Les chercheurs suivent l’opérateur à travers des alias (notamment “knaithe” et “KnYuan”). Selon Unit 42, l’acteur a lancé des tentatives d’exploitation contre plus de 460 cibles, en s’appuyant sur des workflows à la fois autonomes et conventionnels.
Cette approche augmente la vitesse et la portée. Au lieu de ne traiter que quelques systèmes, l’agent peut parcourir des listes, vérifier des versions, télécharger des modules d’exploitation et basculer vers des alternatives lorsqu’un chemin s’avère infructueux.
Sept pistes d’exploits et une logique d’enchaînement via CVE
Unit 42 décrit sept pistes d’exploitation. Le rapport mentionne huit identifiants CVE au total, en partie parce que la chaîne “n8n” combine deux vulnérabilités.
Les chercheurs rapportent aussi des échecs : des attaques menées contre Langflow et n8n n’auraient pas abouti, notamment parce que les systèmes exposés ne satisfaisaient pas aux exigences de configuration nécessaires pour que les exploits fonctionnent.
En clair, l’agent pouvait identifier des cibles “potentielles”, mais sans les paramètres requis (ou sans l’accès public attendu), l’exécution ne donnait pas les résultats escomptés.
Des exploitations manuelles… et des résultats difficiles à concilier
En plus des opérations autonomes, Unit 42 décrit des actions manuelles menées séparément, incluant :
- Exfiltration de données depuis trois organisations via la faille NetScaler memory-overread CVE-2026-3055.
- Exécution de commandes sur 11 instances Marimo via CVE-2026-39987.
Cependant, le rapport avance ensuite qu’il ne peut confirmer que trois cibles réellement exploitées sur l’ensemble de l’opération. Les auteurs notent que le document ne réconcilie pas complètement ces deux affirmations.
Unit 42 indique avoir contacté Palo Alto Networks pour clarification, ce qui suggère que certains détails pourraient nécessiter une mise au point.
Un détail qui trahit l’opération : un serveur HTTP inattendu
Parmi les éléments techniques, un point attire particulièrement l’attention : Hermes Agent aurait démarré python3 -m http.server 8888 depuis /home/worker. Les chercheurs estiment que ce serveur HTTP n’était pas prévu pour être accessible.
Or, cette exposition aurait permis d’accéder à des informations sensibles, notamment : configurations du modèle IA, clés API, scripts d’exploitation, listes de cibles, historique shell et journaux de sessions autonomes.
En pratique, même lorsque l’attaque est “pilotée” par l’IA, les erreurs opérationnelles peuvent créer une surface d’exposition qui facilite l’analyse et l’identification.
Pourquoi certaines chaînes n’ont pas abouti
Les chercheurs détaillent des exemples concrets où l’automatisation s’arrête faute de compatibilité.
Langflow : injection de code sans conditions nécessaires
Lors d’une session récupérée en mai 2026, l’agent aurait téléchargé un exploit public visant la faille CVE-2026-33017 liée à une injection de code dans Langflow. Il aurait aussi interrogé FOFA pour recenser des instances, puis identifié un système en version 1.3.4.
Toutefois, l’attaque s’interrompt car la configuration n’était pas “prête” : notamment, auto_login n’était pas activé et aucun identifiant de flux public exploitable n’a été trouvé.
n8n : reconnaissance massive, mais absence de formulaires exploitables
Ensuite, l’agent aurait examiné environ 10 familles de produits, cherchant sur GitHub des preuves de concept récentes. Il se serait tourné vers n8n, la plateforme d’automatisation de workflows.
La chaîne décrite combine deux vulnérabilités : CVE-2026-21858 (accès non authentifié à des fichiers) et CVE-2025-68613 (injection via expression). Avec FOFA, l’agent aurait récupéré un très grand nombre d’hôtes possibles en Chine (des dizaines de milliers).
Malgré cette ampleur, les chercheurs rapportent que les systèmes ciblés ne permettaient pas d’aboutir : l’agent n’a compromis aucun nœud n8n, notamment parce que plus de 50 autres cibles ne présentaient pas de formulaires publics utilisables. Dans le cas de la cible identifiée, des endpoints de formulaire étaient présents mais nécessitaient une authentification.
Mises à jour de sécurité : versions corrigées citées par Unit 42
À partir des informations fournies, Unit 42 indique plusieurs versions de correction. Les organisations concernées gagneront à comparer leur exposition réelle avec ces repères :
- Langflow : correction de CVE-2026-33017 à partir de 1.9.0.
- n8n : correction de CVE-2026-21858 à partir de 1.121.0.
- n8n : correction de CVE-2025-68613 à partir de 1.120.4, 1.121.1 et 1.122.0.
- Le rapport précise que la version 1.121.1 serait la première qui corrige l’ensemble des deux failles utilisées dans la chaîne testée.
- Marimo : correction de CVE-2026-39987 à partir de 0.23.0.
Ces éléments sont particulièrement importants car, dans l’exemple décrit, l’enchaînement d’exploits dépend de la présence simultanée de vulnérabilités et de configurations compatibles.
NetScaler et SAML : vérifier la configuration des fournisseurs d’identité
Concernant la faille CVE-2026-3055, le rapport attribue l’impact aux instances NetScaler ADC et Gateway administrées par les clients, lorsqu’elles sont configurées comme fournisseurs d’identité SAML.
Unit 42 cite des contrôles pratiques : les administrateurs peuvent examiner la configuration à la recherche d’éléments du type add authentication samlIdPProfile .* puis déployer les correctifs figurant dans le bulletin de sécurité du fournisseur.
Plan d’action recommandé pour réduire le risque
Au-delà des correctifs, l’enquête insiste sur la réduction de l’exposition publique. Les chercheurs recommandent notamment :
- Appliquer les patches pour Langflow, n8n et Marimo.
- Pour les appliances NetScaler administrées par le client, vérifier la configuration SAML et installer les versions corrigées.
- Supprimer l’accès public non nécessaire aux interfaces de workflows et de notebooks (afin de limiter les points d’entrée exploitables).
En parallèle, l’analyse du cas montre qu’une configuration “non compatible” peut stopper la chaîne, même si un système est identifié comme vulnérable sur le papier. Autrement dit, la sécurité ne repose pas uniquement sur la présence d’une faille, mais aussi sur le mode de publication et les paramètres d’accès.
Conclusion
Cette affaire illustre comment DeepSeek via Telegram, intégré dans un agent comme Hermes Agent, peut être utilisé pour automatiser la reconnaissance et orienter l’exploitation à grande échelle. L’opération présentée vise de nombreuses cibles, tout en basculant entre exploits et méthodes selon les résultats observés.
Le message pour les organisations est clair : mettez à jour les produits concernés, réduisez l’exposition publique des interfaces d’automatisation et vérifiez les configurations critiques (notamment SAML sur NetScaler). Les erreurs opérationnelles, comme l’accès involontaire à un serveur HTTP, montrent aussi que la menace peut laisser des traces—mais mieux vaut ne jamais attendre qu’elles soient visibles.
Source: https://thehackernews.com/2026/07/chinese-hacker-commands-deepseek-via.html
