Selon Lumen Black Lotus Labs et des rapports indépendants, le malware PoeLLM avait compromis plus de 3 400 serveurs au 7 octobre 2026. La campagne active Canto Incognito cible des services exposés, notamment LiteLLM, Ollama, Gotenberg et Gitea, puis installe des mineurs de cryptomonnaie et réutilise les hôtes infectés pour rechercher d’autres victimes. Les opérateurs doivent limiter l’exposition, appliquer les correctifs aux services et examiner immédiatement toute utilisation anormale des ressources informatiques.
Qu’est-ce que le logiciel malveillant PoeLLM ?
Le logiciel malveillant PoeLLM est une famille de logiciels malveillants qui transforme des serveurs compromis en mineurs de cryptomonnaies, en scanners réseau et en plateformes de lancement d’exploits. Lumen Black Lotus Labs a publiquement révélé cette famille le 7 octobre 2026, en la présentant comme la charge utile utilisée par une campagne motivée par des raisons financières appelée Canto Incognito, qui était toujours active au moment de la publication.
Le nom peut induire en erreur. PoeLLM n’est pas une intelligence artificielle malveillante et n’est pas connu pour attaquer des modèles de langage au moyen de prompts. Son lien avec l’IA vient de l’infrastructure exposée : les passerelles de modèles accessibles depuis Internet et les serveurs de modèles locaux peuvent fournir aux attaquants une capacité CPU ou GPU précieuse.
Une fois installé, le logiciel malveillant installe les mineurs XMRig et Iron et connecte les charges de minage au service Kryptex, selon un article de The Hacker News publié en 2026. La puissance de traitement volée peut générer des cryptomonnaies pour les opérateurs, tout en augmentant les coûts cloud de la victime, en ralentissant l’inférence et en réduisant la capacité disponible pour les tâches légitimes.
Le minage ne représente qu’une partie des dégâts. BleepingComputer a rapporté en 2026 que les machines compromises servaient également de scanners HTTP et HTTPS et de serveurs d’exploitation. Un point de terminaison de développement négligé peut donc devenir une infrastructure servant à attaquer quelqu’un d’autre, un schéma également observé lorsque le botnet Carbonato a exploité des hôtes Docker exposés.
Comment le logiciel malveillant PoeLLM a-t-il atteint plus de 3 400 serveurs ?
Le logiciel malveillant PoeLLM s’est propagé en recrutant des services vulnérables et accessibles depuis Internet d’au moins avril à octobre 2026. Lumen Black Lotus Labs et des rapports indépendants ont établi le nombre cumulé à plus de 3 400 serveurs au 7 octobre 2026, les infections étant principalement concentrées aux États-Unis et en Europe occidentale plutôt que réparties uniformément dans le monde.
Le premier commit du dépôt GitHub de l’attaquant a été enregistré le 13 avril 2026. Ce dépôt a aidé les systèmes infectés à localiser l’infrastructure de commande et de contrôle, mais la date du commit ne prouve pas que chaque phase de l’infection a commencé ce jour-là.
Les dates publiées permettent de vérifier utilement l’ampleur de la campagne. En divisant plus de 3 400 serveurs compromis par les quelque 177 jours compris entre le 13 avril et le 7 octobre 2026, on obtient une moyenne supérieure à 19 nouvelles victimes comptabilisées par jour. Le recrutement réel n’était pas linéaire : près de 800 systèmes infectés étaient actifs chaque jour au pic de la campagne, à la mi-juin 2026.
Les totaux publiés doivent être interprétés avec prudence. Les informations diffusées autour de la révélation du 7 octobre 2026 ont actualisé les estimations antérieures, qui faisaient état d’environ 2 100 à 2 200 victimes, pour les porter à plus de 3 400, tandis qu’une partie des documents de Lumen aurait conservé le chiffre inférieur. L’interprétation la plus défendable est celle de plus de 3 400 compromissions cumulées, et non de 3 400 machines actives simultanément.
Black Lotus Labs a découvert l’opération plus vaste en juin 2026, alors qu’il enquêtait sur un système Ivanti Sentry associé à CVE-2026-10520, a rapporté The Register. Cette découverte n’établit pas qu’Ivanti Sentry soit le point d’entrée de chaque victime. Considérer un appareil faisant l’objet d’une enquête comme un vecteur d’infection universel orienterait les défenseurs dans la mauvaise direction.
Quels services accessibles depuis Internet la campagne a-t-elle ciblés ?
Le logiciel malveillant PoeLLM a ciblé des services LiteLLM, Ollama, Gotenberg et Gitea exposés en 2026, tandis que les chercheurs ont également trouvé des éléments impliquant Ivanti Sentry. L’ensemble des systèmes concernés couvre les passerelles d’IA, la fourniture de modèles locaux, la conversion de documents et l’infrastructure destinée aux développeurs, ce qui montre que la campagne suit les ressources de calcul accessibles et les services exploitables plutôt qu’une seule catégorie de produits précisément définie.
| Service | Rôle typique | Lien avec la campagne de 2026 signalé |
|---|---|---|
| LiteLLM | Passerelle et proxy pour les API de modèles de langage | Cible observée |
| Ollama | Fourniture locale de grands modèles de langage | Cible observée |
| Gotenberg | API de conversion de documents conteneurisée | Cible observée |
| Gitea | Service Git auto-hébergé | Cible observée |
| Ivanti Sentry | Composant de passerelle mobile | Éléments indiquant un ciblage ; non établi comme vecteur d’infection de chaque victime |
Cette diversité est importante. Gotenberg et Gitea ne sont pas des serveurs de grands modèles de langage, mais ils répondent tous deux aux critères pratiques d’un attaquant : des services applicatifs accessibles, une puissance de calcul ou des accès utiles, et des possibilités de passer d’un système exposé au suivant. Qualifier Canto Incognito de simple « attaque de serveurs d’IA » masque l’ampleur de ce risque opérationnel.
Les outils destinés aux développeurs méritent le même niveau d’examen que les points de terminaison d’inférence en production. Des incidents récents impliquant une faille de JFrog Artifactory et des portes dérobées persistantes et une vulnérabilité critique de GitLab exploitée dans la nature illustrent pourquoi les dépôts et les systèmes de compilation ne doivent pas être exclus des examens habituels de l’exposition.
Pourquoi le logiciel malveillant utilise-t-il un poème sur GitHub ?
Le logiciel malveillant PoeLLM lit quatre mots ou expressions dans un poème hébergé sur GitHub et les fait correspondre à un dictionnaire intégré afin de reconstituer l’adresse IPv4 actuelle de son serveur de commande et de contrôle. Cette technique de 2026 permet à l’opérateur de rediriger les serveurs infectés en modifiant un texte public, sans devoir envoyer un nouveau binaire malveillant à chaque hôte compromis.
Le poème n’est pas un artifice littéraire ajouté à un mécanisme ordinaire de commande et de contrôle. Il s’agit d’un mécanisme compact d’indirection. Des informations publiées en 2026 ont documenté 11 modifications du poème et 12 adresses identifiées, démontrant que l’opérateur pouvait faire tourner les destinations tout en conservant la même logique de recherche sur les machines infectées.
Il n’est pas allégué que GitHub participe à l’attaque ; le contenu de son dépôt a été détourné comme canal de découverte. Les défenseurs qui bloquent uniquement un serveur de commande connu peuvent donc n’obtenir qu’un répit temporaire tout en passant à côté du comportement stable : récupération de contenu public, décodage local, puis connexion à une adresse IPv4 nouvellement dérivée.
Trois adresses de commande identifiées seraient encore actives le 7 octobre 2026, même si Lumen avait placé en null-routing l’infrastructure visible via son propre réseau. Soyons clairs : une liste statique de blocage d’adresses IP est trop fragile pour constituer la défense principale dans ce cas. Une politique de sortie et une détection comportementale offrent un contrôle plus durable.
Comment les opérateurs doivent-ils détecter et stopper le logiciel malveillant PoeLLM ?
Les opérateurs doivent contenir le logiciel malveillant PoeLLM en supprimant les expositions Internet inutiles, en exigeant une authentification, en appliquant les correctifs aux services concernés et en isolant les conteneurs selon le principe du moindre privilège. En 2026, les défenseurs doivent également renouveler les identifiants exposés, restreindre les connexions sortantes et enquêter sur toute consommation inexpliquée de CPU ou de GPU, le trafic vers des pools de minage, les analyses à grande échelle et les comportements liés à la mise à disposition d’exploits.
Commencez par le service accessible, et non par le nom du logiciel malveillant. Un point de terminaison de modèle ou une interface d’administration sans authentification peut être retrouvé après la suppression d’un mineur. Placez les charges de travail privées derrière un VPN, un proxy tenant compte de l’identité ou une règle de pare-feu strictement limitée, puis vérifiez depuis un réseau externe que le port d’origine n’est plus public.
L’ordre d’intervention suivant traite à la fois l’exposition initiale et la capacité de l’hôte compromis à se propager :
- Recensez les systèmes LiteLLM, Ollama, Gotenberg, Gitea et Ivanti Sentry accessibles depuis Internet, y compris les déploiements de test temporaires et les instances cloud créées en dehors du provisionnement standard.
- Supprimez l’accès public lorsqu’il n’est pas nécessaire ; sinon, imposez une authentification, des restrictions de source et des limites de débit adaptées au service.
- Appliquez les correctifs des fournisseurs et consultez les consignes de mise à jour pour chaque produit concerné, plutôt que de supposer qu’une seule vulnérabilité explique la campagne de 2026.
- Mettez en quarantaine les hôtes suspects, conservez les journaux et examinez les conteneurs, les processus, les tâches planifiées et les mécanismes de persistance avant de reconstruire le système à partir d’une image fiable.
- Faites tourner les clés API, les jetons de service, les identifiants SSH et les secrets accessibles depuis l’hôte, y compris les identifiants montés à l’intérieur des conteneurs.
- Restreignez les accès sortants et déclenchez des alertes en cas de connexions à Kryptex ou à des pools de minage, de saturation prolongée des ressources de calcul, de balayages à l’échelle d’Internet et de trafic d’exploitation inattendu.
Le principe du moindre privilège comporte ici deux volets. Exécutez les conteneurs sans permissions excessives sur l’hôte et limitez les destinations réseau auxquelles ces charges de travail peuvent accéder. Les contrôles d’exécution font de plus en plus partie intégrante de la pratique de la gouvernance de l’IA pour les systèmes de production, car les documents de politique ne peuvent pas empêcher un conteneur détourné de miner ou d’effectuer des balayages.
Ne considérez pas un faible trafic d’inférence comme une preuve de sécurité. Un serveur compromis peut présenter peu d’utilisation légitime des modèles tandis que son processeur reste monopolisé par XMRig ou Iron. Comparez les niveaux de référence du calcul, du réseau et de la facturation avec ceux de la même charge de travail et de la même période ; une utilisation soudainement élevée et soutenue sans volume de requêtes correspondant mérite une enquête immédiate.
Black Lotus Labs a attribué Canto Incognito à un acteur italophone avec un niveau de confiance modéré en 2026, sur la base d’artefacts en langue italienne et d’indicateurs issus des flux réseau. Cette attribution ne devrait pas modifier les priorités de confinement. Les chercheurs ont également observé du trafic vers SSH et d’autres portails de connexion, ce qui pourrait indiquer des expérimentations de force brute, mais la maturité de cette capacité demeurait incertaine en 2026.
Questions fréquemment posées sur PoeLLM
PoeLLM est-il un virus généré par l’IA ?
Il n’est pas signalé que PoeLLM soit un virus généré par l’IA. Le nom du logiciel malveillant fait référence à la découverte de son serveur de commande fondée sur des poèmes et au ciblage d’infrastructures exposées, notamment des services d’IA.
PoeLLM infecte-t-il uniquement les serveurs Ollama ?
PoeLLM a affecté davantage de déploiements qu’Ollama en 2026. Les cibles observées comprenaient LiteLLM, Gotenberg et Gitea, avec des éléments supplémentaires impliquant Ivanti Sentry.
La suppression du cryptomineur élimine-t-elle l’infection ?
La suppression de XMRig ou d’Iron seule ne permet pas d’établir qu’un hôte compromis est sain. Les opérateurs doivent isoler le serveur, examiner les activités de persistance et de balayage, faire tourner les secrets accessibles, corriger l’exposition initiale et reconstruire le système à partir d’une image de confiance lorsque l’intégrité ne peut pas être démontrée.
La campagne était-elle toujours active en octobre 2026 ?
Canto Incognito recrutait encore des systèmes vulnérables exposés à Internet lorsque les chercheurs ont révélé la campagne le 7 octobre 2026. Les informations publiées jusqu’au 12 octobre 2026 continuaient de faire état de plus de 3 400 serveurs affectés, sans qu’un total sensiblement plus récent et fiable ait été identifié au 13 octobre 2026.