Le 2 novembre 2026, le canal de mise à jour de cPGuard a distribué un script malveillant aux serveurs Linux utilisant les versions 5.88.12 à 5.88.19, selon les informations attribuées à OPSSHIELD. Le script pouvait installer une porte dérobée et collecter des fichiers sensibles. Pour évaluer un serveur, il faut distinguer l’installation d’une version touchée de l’exécution du script, puis traiter séparément les logiciels et les identifiants susceptibles d’avoir été exposés.
Comment le script est arrivé sur des serveurs Linux
OPSSHIELD a situé le début de l’intrusion sur son serveur de facturation et de licences, le 1er novembre. L’attaquant aurait obtenu un accès permettant d’exécuter des commandes à 22 h 58 UTC. Le 2 novembre, le script aurait été envoyé au système de mise à jour entre 2 h 04 et 2 h 09 UTC, puis installé sur des serveurs clients entre 2 h 08 et 3 h 20 UTC.
Le script aurait installé un shell caché doté des privilèges root et créé une tâche planifiée. Il aurait aussi lu des fichiers pouvant contenir des informations sensibles : /etc/shadow, /etc/passwd, les fichiers SSH de root, /root/.my.cnf et l’historique de commandes de root. Le fichier /root/.s3cfg, qui peut contenir des identifiants cloud, aurait été visé sur un petit nombre de serveurs. Ces éléments ne signifient pas que chaque fichier ou identifiant était présent sur chaque machine.
Vérifier si une mise à jour touchée a été installée
OPSSHIELD a associé l’incident aux versions 5.88.12 à 5.88.19. Pour consulter le journal d’installation de cPGuard, le compte rendu de l’incident indique cette commande :
grep 'Successfully updated' /opt/cpguard/logs/install_log
Une entrée correspondant à une version touchée indique que la mise à jour a été installée. À elle seule, elle ne prouve pas que le script s’est exécuté ni que des données ont quitté le serveur. À l’inverse, un journal absent ou incomplet ne permet pas d’écarter une exposition. Des fichiers malveillants peuvent aussi avoir disparu après une mise à jour sans que cela prouve que le script n’a jamais été exécuté.
Indicateurs et données concernés
Parmi les traces signalées figurent le shell /var/tmp/.cpg91511_sh, la tâche planifiée /etc/cron.d/i93677 et le répertoire /var/tmp/.i93677/. Le script aurait également créé /var/tmp/.cpg91511/loot.tgz, une archive liée à la collecte de fichiers. L’adresse réseau signalée pour l’attaquant est 94.183.188[.]91.
Les fichiers du script mentionnés sont cpguard-v58812-i91511.sh et des variantes dont le nom se termine par b, c ou d. Les empreintes SHA-256 associées dans le signalement sont :
2c2acd988da531d133d0e17f245c49bf15781278f837543d18c95e8410eabd38ffd7a47f65fa1244429baa936ae94be54676b53d2f88bc39564f24e22011de8ad73919af84bf46de941db85e27fd1abc65701ef9ce6cf33bb27c5397f4a41c266add0201e9a3d02de772d561d05e0da86eb1c538686753b7adcc3aedf7366f77
Les fichiers et identifiants concernés comprennent notamment des mots de passe, des clés SSH, des identifiants de base de données et des secrets cloud. L’historique de commandes de root peut lui aussi contenir des secrets. Leur présence dépend de chaque serveur.
Les chiffres rapportés et les mises à jour correctives
OPSSHIELD a estimé qu’environ 2 950 serveurs clients avaient exécuté le script. L’entreprise a également indiqué que des dossiers de facturation associés à environ 7 900 comptes avaient été dérobés et que trois de ses serveurs cloud avaient été copiés. Une estimation initiale portait sur 32 fichiers pris sur le serveur de licences, chacun associé à un serveur client : ce chiffre ne mesure pas le nombre total de serveurs sur lesquels le script s’est exécuté.
La version 5.88.25 a d’abord été citée comme correctif. Une précision ultérieure attribuait à la version 5.88.26 la suppression de la porte dérobée ; une mise à jour distincte retire la tâche planifiée. La suppression de la porte dérobée et celle de la tâche correspondent donc à deux actions de mise à jour.
Réponse à suivre sur un serveur potentiellement exposé
La réponse rapportée par OPSSHIELD comprend plusieurs étapes : mettre à jour cPGuard, rechercher les traces restantes et les supprimer, puis renouveler les secrets susceptibles d’avoir été copiés. Renouveler les mots de passe ne remplace pas le nettoyage du logiciel, et la mise à jour ne rend pas sûrs des identifiants qui auraient déjà été collectés.
Renouvelez les mots de passe locaux et ceux qui ont été réutilisés ailleurs, ainsi que les identifiants de base de données et de services cloud concernés. Remplacez les clés SSH potentiellement exposées, vérifiez authorized_keys et retirez les anciennes clés publiques de confiance. Les identifiants du portail de facturation d’OPSSHIELD font aussi partie des éléments à renouveler dans les mesures rapportées.
OPSSHIELD ne recommandait pas de reconstruire systématiquement tous les systèmes. Le compte rendu décrit plutôt une évaluation au cas par cas ; une reconstruction depuis une sauvegarde saine était recommandée lorsque l’entreprise confirmait une connexion manuelle de l’attaquant.
