cPGuard est une extension de sécurité pour serveurs cPanel, DirectAdmin et CWP, éditée par la société OPSSHIELD. Entre le 2 et le 3 novembre 2026, un attaquant qui a pris le contrôle du canal de mise à jour du logiciel a diffusé des versions piégées qui volaient mots de passe, configuration de base de données et clés SSH sur les serveurs concernés. OPSSHIELD a détecté l’intrusion en une douzaine d’heures, coupé la diffusion et publié un correctif.
Qu’est-ce que cPGuard et que s’est-il passé ? #
cPGuard sécurise les panneaux d’hébergement Linux (cPanel/WHM, DirectAdmin, CWP) contre les malwares et intrusions. Selon l’avis officiel d’OPSSHIELD, un attaquant a utilisé des identifiants compromis pour accéder au système de distribution des mises à jour le 2 novembre 2026 à 02h06 UTC, et a diffusé un script malveillant à la place d’une mise à jour légitime. Ce script a été envoyé dans les versions 5.88.12 à 5.88.19 de cPGuard.
L’incident est une attaque de la chaîne d’approvisionnement logicielle : les clients n’ont rien téléchargé de suspect eux-mêmes, c’est le canal de mise à jour auquel ils font confiance par défaut qui a été détourné. The Hacker News relève que ce type de compromission touche en priorité les hébergeurs et agences qui gèrent de nombreux serveurs Linux en parallèle, souvent avec des mises à jour automatiques.
Chronologie de l’attaque #
| Date (UTC) | Événement |
|---|---|
| 2 novembre, 02h06 | L’attaquant accède au canal de mise à jour avec des identifiants compromis et diffuse le script piégé. |
| 2 novembre, ~14h | OPSSHIELD détecte l’attaque, environ douze heures après le début de la diffusion. |
| 2-3 novembre | OPSSHIELD sécurise le compte compromis, coupe la diffusion et estime que l’attaquant a récupéré 32 fichiers de collecte, un par serveur client touché. |
| 3 novembre | OPSSHIELD publie son avis officiel et la version corrigée 5.88.25, qui retire la porte dérobée et les fichiers déposés. |
OPSSHIELD précise que l’enquête sur l’origine des identifiants compromis se poursuit, sans donner de date de résolution.
Quelles données ont été volées ? #
Le script piégé collectait sur chaque serveur touché :
- le fichier
/etc/shadowet/etc/passwd, qui contiennent les empreintes (hash) des mots de passe système ; - la configuration MariaDB/MySQL du compte root (
my.cnf) ; - l’historique shell du compte root ;
- les clés et hôtes connus SSH du compte root (
authorized_keys,known_hosts).
Ces données étaient envoyées vers un serveur de licence d’OPSSHIELD, sous un compte lui aussi compromis, où l’attaquant pouvait les récupérer. OPSSHIELD confirme qu’une partie a bien été récupérée, sans savoir encore laquelle avec certitude : l’éditeur précise que tous les fichiers n’ont pas forcément été collectés sur chaque serveur. Un script installait en parallèle une porte dérobée (/var/tmp/.cpg91511_sh), ce qui peut permettre un accès ultérieur même après la mise à jour corrective.
Que faire si vous utilisez cPGuard ? #
- Mettez à jour immédiatement vers la version 5.88.25 ou ultérieure (
cpgcli update --start), puis vérifiez le numéro de version aveccpgcli --version. - Vérifiez l’historique des mises à jour (
grep 'Successfully updated' /opt/cpguard/logs/install_log) : toute trace d’une version comprise entre 5.88.12 et 5.88.19 signifie que le serveur a potentiellement exécuté le script piégé, même s’il tourne aujourd’hui sous une version corrigée. - Si le script a pu s’exécuter, changez tous les mots de passe locaux (root compris) depuis un environnement de récupération de confiance, et changez aussi tout mot de passe réutilisé ailleurs.
- Faites tourner vos secrets : mots de passe de base de données, clés d’accès S3 ou d’hébergeur, et tout identifiant présent dans l’historique shell de root.
- Remplacez les clés SSH privées du dossier
/root/.sshet retirez les anciennes clés publiques correspondantes des systèmes qui leur faisaient confiance. - Recherchez les indicateurs connus : le script
cpguard-v58812-i91511.sh, la porte dérobée/var/tmp/.cpg91511_shet le répertoire/var/tmp/.cpg91511. Leur absence ne garantit toutefois pas qu’aucune exécution n’a eu lieu.
L’avis de ForenShield #
Priorité numéro un : tout serveur ayant appliqué une version 5.88.12 à 5.88.19 de cPGuard doit être traité comme potentiellement compromis, pas seulement mis à jour. La mise à jour corrective retire la porte dérobée connue, mais elle ne restaure pas la confidentialité d’un mot de passe ou d’une clé déjà exfiltrés : c’est la rotation des secrets qui ferme réellement l’incident, pas le seul numéro de version affiché.
Côté détection, ce type d’attaque de la chaîne d’approvisionnement laisse des traces précises à chercher dans les journaux : exécutions inhabituelles au moment exact d’une mise à jour automatique, connexions sortantes vers un domaine ou une IP inconnue juste après l’installation d’un paquet, lecture du fichier /etc/shadow par un processus qui n’est ni un outil d’administration ni un gestionnaire de paquets, ou apparition de fichiers dans des répertoires temporaires comme /var/tmp ou /dev/shm sans action humaine identifiée.
Le piège classique, ici, consiste à se contenter de la mise à jour corrective sans rotation des secrets : un attaquant qui a déjà exfiltré une clé SSH ou un mot de passe root garde un accès valide tant que ces identifiants n’ont pas changé, même sur un serveur à jour. Un autre piège consiste à ne traiter que les serveurs où les indicateurs connus sont présents : l’éditeur lui-même indique que leur absence ne prouve rien, puisque le script n’a pas nécessairement laissé les mêmes traces partout. Après remédiation, il convient de surveiller les connexions et tentatives d’authentification pendant plusieurs semaines, en particulier avec les identifiants qui viennent d’être changés.
Points clés #
- Entre le 2 et le 3 novembre 2026, un canal de mise à jour compromis a diffusé des versions piégées de cPGuard (5.88.12 à 5.88.19) qui volaient mots de passe, configuration base de données et clés SSH.
- OPSSHIELD a détecté l’attaque en une douzaine d’heures, coupé la diffusion et publié la version corrigée 5.88.25, qui retire la porte dérobée installée.
- L’enquête sur l’origine des identifiants compromis utilisés par l’attaquant se poursuit chez OPSSHIELD.
- La mise à jour seule ne suffit pas : tout serveur ayant appliqué une version affectée doit faire l’objet d’une rotation complète des mots de passe, clés SSH et secrets applicatifs.
- L’absence des indicateurs connus (fichiers, porte dérobée) ne prouve pas l’absence de compromission, selon l’éditeur lui-même.
Après une rotation de mots de passe, le générateur de mots de passe de ForenShield permet de créer des identifiants longs et uniques pour chaque service. D’autres compromissions récentes de la chaîne d’approvisionnement logicielle sont détaillées dans nos articles sur l’attaque visant AOMEI Backupper et sur la technique SlugFest ciblant des paquets npm.