Des systèmes compromis deviennent des mineurs et des infrastructures d’attaque
Une opération de minage de cryptomonnaies utilisant le malware PoeLLM a compromis plus de 2 100 serveurs, selon Black Lotus Labs, une division de Lumen. Au plus fort de l’activité, les chercheurs ont observé jusqu’à 800 systèmes infectés actifs en une journée.
Les conclusions ont été rapportées par BleepingComputer le 7 octobre 2026 à 11 h 04. Black Lotus Labs indique que l’activité de PoeLLM remonte au moins au mois d’avril, sans préciser l’année de début.
La campagne a ciblé des systèmes aux États-Unis et en Europe de l’Ouest. Parmi les victimes identifiées, nombreuses sont celles qui exploitaient des instances de LiteLLM ou d’Ollama accessibles depuis Internet, le logiciel de conversion PDF Gotenberg ou la boîte à outils de développement Gitea. Les chercheurs ont également relevé des indices indiquant que Ivanti Sentry était visé.
Le minage n’est qu’un volet de l’opération. PoeLLM donne à son opérateur un accès à un shell distant et peut transformer un système infecté en plateforme de balayage HTTP/S et de nouvelles tentatives d’exploitation. Le malware intègre également les mineurs de cryptomonnaies XMRig et Iron.
Black Lotus Labs a observé des systèmes compromis communiquer avec Kryptex, que l’organisation décrit comme un service russe de minage de cryptomonnaies. Les chercheurs estiment que les déploiements d’IA et de grands modèles de langage attirent les attaquants, car certains sont exposés ou mal configurés et peuvent disposer de ressources GPU adaptées au minage.
Cette analyse ne signifie pas que toutes les victimes exploitaient des serveurs d’IA. Les systèmes concernés incluent également des logiciels de développement et de conversion de documents.
Un poème hébergé sur GitHub détermine l’adresse C2
PoeLLM est un échantillon de malware ELF nommé libgcrypt. Pour trouver son serveur de commande et de contrôle, il s’appuie sur un texte récupéré dans un dépôt GitHub qui semble être un fork de Node.js.
Le malware extrait quatre mots ou expressions de « On the Nature of Connection », un poème stocké dans un fichier nommé dash.css. Il traite ces termes à l’aide d’un dictionnaire codé en dur, les convertit en nombres, puis utilise le résultat pour construire une adresse IPv4 destinée aux communications de commande et de contrôle.
Toute modification du poème change l’adresse générée par ce processus. Black Lotus Labs indique que l’opérateur a modifié le poème à 11 reprises et soupçonne qu’au moins une autre mise à jour a eu lieu. Les chercheurs ont également observé la mise en service d’au moins 11 serveurs C2.
L’analyse de cette infrastructure a révélé des interfaces d’administration de routeurs vulnérables sur plusieurs systèmes C2. Black Lotus Labs avance que l’opérateur a peut-être réutilisé des routeurs compromis, mais les informations disponibles ne permettent pas de confirmer cette hypothèse.
PoeLLM est le nom du malware, pas celui d’un groupe de cybercriminels. Black Lotus Labs n’a pas pu attribuer l’opération avec certitude à un acteur connu. Les chercheurs estiment, avec un niveau de confiance modéré, que l’opérateur est italien, en se fondant sur des commentaires découverts dans le malware et sur la présence d’un serveur hébergeant l’interface d’administration en Italie.
Les scans ciblent les ports 3000 et 4000
Après avoir compromis un serveur, l’opération peut l’utiliser pour rechercher d’autres services sur les ports 3000 et 4000. Selon les informations publiées, ces ports sont associés aux déploiements de Gotenberg et de LiteLLM.
PoeLLM peut ensuite tenter d’exploiter CVE-2026-42271, une vulnérabilité d’exécution de commandes touchant la fonctionnalité de test du serveur MCP de LiteLLM. Les activités de balayage et la capacité d’exploitation observées ne prouvent pas que cette vulnérabilité a servi à obtenir un accès initial à chacune des machines infectées.
La faille touche deux points de terminaison utilisés pour tester un serveur MCP avant l’enregistrement de sa configuration :
POST /mcp-rest/test/connectionPOST /mcp-rest/test/tools/list
De LiteLLM 1.74.2 jusqu’aux versions antérieures à 1.83.7, les deux points de terminaison acceptaient une configuration complète du serveur MCP dans le corps de la requête. Celle-ci pouvait contenir les champs command, args et env utilisés par le transport stdio.
Lorsqu’un point de terminaison recevait une configuration stdio, le proxy tentait d’établir la connexion demandée. Pour ce faire, il lançait la commande fournie en tant que sous-processus sur l’hôte, avec les privilèges attribués au processus proxy de LiteLLM.
Une clé API de proxy valide était nécessaire, mais les points de terminaison n’effectuaient aucune vérification des rôles. Un utilisateur authentifié pouvait donc exécuter des commandes arbitraires, même avec une clé d’utilisateur interne disposant de faibles privilèges. La vulnérabilité a été corrigée dans LiteLLM 1.83.7.
CVE-2026-42271 a un score CVSS v3 de 8.8 et le vecteur CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. Les classifications enregistrées sont CWE-77, CWE-78 et une deuxième occurrence de CWE-78.
Les produits et versions concernés sont les suivants :
- LiteLLM dans les versions antérieures à 1.83.7 ; la description de la vulnérabilité porte précisément sur les versions de 1.74.2 à celles antérieures à 1.83.7
- Red Hat OpenShift AI dans les versions antérieures à 2.25.8
Une chaîne d’exploitation signalée supprime l’authentification requise
BleepingComputer rapporte que les chercheurs de Horizon.ai ont confirmé qu’il était possible de chaîner CVE-2026-42271 avec CVE-2026-48710 pour obtenir une exécution de code à distance sans authentification.
Cette qualification d’exécution de code à distance concerne la chaîne d’exploitation signalée. La description de CVE-2026-48710 par la NVD documente séparément une faiblesse de validation de l’en-tête Host et un possible contournement des contrôles de sécurité ; elle ne décrit pas la vulnérabilité prise isolément comme une faille d’exécution de code à distance.
CVE-2026-48710 touche Starlette dans les versions antérieures à 1.0.1. Dans les versions vulnérables, l’en-tête de requête HTTP Host n’était pas validé avant que Starlette l’utilise pour reconstruire request.url.
Le routage repose sur le chemin HTTP brut, tandis que l’URL reconstruite intègre la valeur Host fournie. Un en-tête mal formé pouvait donc faire en sorte que request.url.path ne corresponde pas au chemin réellement demandé par le client.
Cette divergence pouvait compromettre les intergiciels ou les points de terminaison qui appliquent des restrictions de sécurité à partir de request.url plutôt que du chemin brut scope. Starlette 1.0.1 valide l’en-tête conformément aux normes RFC 9112 §3.2 et RFC 3986 §3.2.2, et utilise scope["server"] lorsqu’il rencontre une valeur mal formée.
Cette vulnérabilité a un score CVSS v3 de 6.5 et le vecteur CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N. Ses classifications sont CWE-444 et CWE-1289.
Les produits concernés sont les suivants :
- Encode Starlette dans les versions antérieures à 1.0.1
- Red Hat AI Inference Server jusqu’à la version 3.3.5 incluse
- Red Hat Ansible Automation Platform 2.6
- Red Hat Migration Toolkit for Applications dans les versions antérieures à 8.2.0
- Red Hat OpenShift AI dans les versions antérieures à 3.3.5
- Red Hat OpenShift Lightspeed, sans version précisée dans les données fournies
- Red Hat Satellite 6.17
- Red Hat Enterprise Linux AI 3.0
La CISA répertorie les deux failles parmi les vulnérabilités exploitées
La CISA a ajouté CVE-2026-42271 à son catalogue des vulnérabilités exploitées (KEV) le 8 juin 2026. Les agences fédérales américaines concernées avaient jusqu’au 22 juin 2026 pour appliquer les mesures correctives.
La CISA demande d’appliquer les mesures d’atténuation conformément aux instructions du fournisseur, de suivre les directives applicables de BOD 22-01 pour les services cloud ou de cesser d’utiliser le produit si aucune mesure d’atténuation n’est disponible.
CVE-2026-48710 a été ajoutée au catalogue KEV le 2 septembre 2026, avec une date limite de mise en conformité fixée au 16 septembre 2026 pour les agences fédérales américaines. La CISA demande d’appliquer les mesures d’atténuation préconisées par le fournisseur, en suivant BOD 26-04, Prioritizing Security Updates Based on Risk et ses Forensics Triage Requirements.
La directive impose également de suivre les recommandations applicables de BOD 26-04 pour les services cloud ou de cesser d’utiliser le produit lorsqu’aucune mesure d’atténuation n’est disponible. Les parties prenantes doivent évaluer l’exposition à Internet de chaque actif et suivre les recommandations de mise à jour de BOD 26-04.
Ces dates sont des échéances de mise en conformité pour les agences fédérales, et non des délais généraux applicables à toutes les organisations.
D’autres vulnérabilités liées aux mêmes fournisseurs — Red Hat, LiteLLM ou Encode — ont également été ajoutées au catalogue KEV au cours des 90 derniers jours : CVE-2026-59822 le 2 septembre 2026, CVE-2015-5287 et CVE-2015-3246 le 26 août 2026, ainsi que CVE-2026-34486 le 4 août 2026.
Croiser exposition, processus et activité réseau pour détecter les menaces
Les administrateurs devraient recenser, le cas échéant, les services LiteLLM, Ollama, Gotenberg, Gitea et Ivanti Sentry accessibles depuis Internet. Il convient de limiter l’exposition des systèmes critiques en restreignant leur accès externe à des adresses IP de confiance.
Pour corriger CVE-2026-42271, les déploiements LiteLLM doivent être mis à niveau vers la version 1.83.7 ou une version ultérieure. Les utilisateurs de Starlette doivent passer à la version 1.0.1 ou ultérieure, tandis que les opérateurs des produits Red Hat concernés doivent suivre les instructions correspondantes du fournisseur.
Parmi les éléments utiles à examiner figurent les balayages visant les ports 3000 et 4000, les commandes lancées de façon inattendue avec les privilèges du processus proxy de LiteLLM, la récupération de dash.css et la présence d’un fichier ELF nommé libgcrypt. Ces éléments comportementaux ou contextuels ne constituent pas, pris isolément, des preuves concluantes de compromission.
Black Lotus Labs a publié des indicateurs de compromission à rechercher dans les journaux réseau. Cet article n’en reprend pas les valeurs : les équipes de défense doivent consulter les publications des chercheurs avant de lancer des recherches fondées sur ces indicateurs.
L’attribution doit rester distincte de la détection. Les éléments disponibles étayent, avec un niveau de confiance modéré, l’hypothèse d’une origine italienne de l’opérateur, mais ne permettent ni de confirmer son identité ni de l’associer à un groupe de cybercriminels connu.
