Une fausse mise à jour de cPGuard a volé les secrets root d’environ 2 950 serveurs d’hébergement web

cPGuard est une suite de sécurité pour serveurs web Linux : analyse antimaliciel, pare-feu et protection contre les attaques, souvent utilisée par des hébergeurs à côté de panneaux de contrôle comme cPanel, DirectAdmin et Plesk. BleepingComputer note que Namecheap l’offre sur ses serveurs VPS et dédiés. Le 2 novembre, l’outil censé protéger ces serveurs a été retourné contre eux. Un attaquant a poussé une fausse mise à jour de cPGuard qui s’exécutait en tant que root et envoyait ailleurs les fichiers les plus sensibles du serveur. OPSSHIELD, la petite entreprise derrière cPGuard, a publié une divulgation complète (en anglais) le 3 novembre. Voici comment c’est arrivé et quoi faire.

Ce qui s’est passé

OPSSHIELD dit que l’attaquant s’est inscrit comme client, a utilisé ce compte pour entrer dans son serveur de facturation et de licences, a pris les clés qui servent à publier les mises à jour et a diffusé une fausse mise à jour de cPGuard pendant environ 70 minutes. Sa chronologie, en UTC :

OPSSHIELD dit que ses journaux n’enregistrent pas la requête exacte qui a donné accès à l’attaquant. Elle examine donc le code de l’application de facturation et a corrigé deux points d’entrée possibles. Elle a écarté SSH, le panneau de contrôle, FTP et les jetons d’API. Son avis précédent (en anglais) indique que les versions 5.88.12 à 5.88.19 de cPGuard sont les mises à jour touchées.

Ce qui a été pris

La fausse mise à jour était un court script, et non un implant de longue durée. Sur les serveurs qui l’ont exécutée, OPSSHIELD dit qu’elle a lu :

• /etc/shadow et /etc/passwd, les empreintes des mots de passe locaux du serveur
• /root/.ssh, y compris les clés SSH privées de root et la liste des clés autorisées à se connecter
• /root/.my.cnf, qui contient souvent le mot de passe root de MySQL
• l’historique du shell de root, qui contient souvent des mots de passe et des jetons tapés en ligne de commande
• les clés de stockage infonuagique de /root/.s3cfg, sur un petit nombre de serveurs

Elle a aussi laissé deux choses derrière elle : un shell root caché à /var/tmp/.cpg91511_sh et des fichiers dans /var/tmp/.i93677/, ainsi qu’une tâche planifiée à /etc/cron.d/i93677.

Un porte-parole a dit à BleepingComputer (en anglais) que le nombre exact était de 2 946 serveurs, et que la base de données du système de facturation avait aussi été copiée. OPSSHIELD dit que l’attaquant a aussi copié trois de ses propres serveurs infonuagiques.

Pourquoi c’est important, même si vous n’avez jamais entendu parler de cPGuard

La plupart des personnes touchées ne le sauront pas. Si votre site web, votre boutique en ligne ou votre courriel est hébergé par un petit ou moyen hébergeur, il est possible qu’un de ses serveurs ait utilisé cPGuard. Un accès root à un serveur d’hébergement mutualisé peut donner accès à chaque site, base de données et boîte courriel qui s’y trouve. OPSSHIELD n’a pas dit que l’attaquant s’est servi des secrets volés pour entrer dans des sites de clients, et rien de public ne le montre jusqu’ici. Mais les secrets ont été pris : les hébergeurs doivent donc les remplacer avant que quelqu’un essaie.

On retrouve aussi le même schéma que dans d’autres attaques de la chaîne d’approvisionnement récentes : l’attaquant n’entre pas dans des milliers de serveurs un par un, il entre dans le seul endroit auquel ces serveurs font confiance pour leurs mises à jour. Dans sa divulgation, OPSSHIELD dit que ce genre d’attaque devient plus rapide et moins coûteux parce que les attaquants utilisent des outils d’IA pour repérer les failles et écrire des outils sur mesure, et que les quelque dix heures entre le premier sondage et la fausse mise à jour en sont le reflet. C’est l’avis de l’entreprise sur la tendance, et non une conclusion sur l’auteur de cette attaque.

Si vous exploitez un serveur avec cPGuard

OPSSHIELD dit que ces étapes prennent moins d’une heure par serveur pour la plupart des administrateurs :

1. Vérifiez si vous avez reçu une mauvaise mise à jour. Lancez grep 'Successfully updated' /opt/cpguard/logs/install_log et cherchez les versions 5.88.12 à 5.88.19. La divulgation d’OPSSHIELD dit que les serveurs où cPGuard était hors ligne entre 2 h 08 et 3 h 20 UTC le 2 novembre ne l’ont pas reçue, mais le journal d’installation reste la vérification la plus sûre.
2. Mettez cPGuard à jour vers la dernière version (au moins 5.88.26), puis assurez-vous que /etc/cron.d/i93677, /var/tmp/.i93677/ et /var/tmp/.cpg91511_sh ont disparu. Sinon, supprimez-les.
3. Changez le mot de passe root et celui de chaque utilisateur local.
4. Générez de nouvelles clés SSH root, retirez les anciennes du fichier authorized_keys de chaque serveur qui leur faisait confiance et cherchez des clés que vous ne reconnaissez pas. Considérez comme exposés les autres serveurs que celui-ci pouvait joindre par SSH, jusqu’à ce que leurs clés soient remplacées.
5. Changez le mot de passe root de MySQL et tout mot de passe de base de données dans /root/.my.cnf, et remplacez tout mot de passe, clé d’API ou jeton présent dans l’historique du shell de root ou dans /root/.s3cfg.
6. Réinitialisez votre mot de passe de manage.opsshield.com et activez la connexion à deux facteurs, même si vos serveurs n’ont pas reçu la mise à jour.
7. Si OPSSHIELD vous a dit que l’attaquant s’est connecté à votre serveur à la main, reconstruisez-le à partir d’une sauvegarde saine faite avant le 1er novembre.

OPSSHIELD dit qu’elle aidera gratuitement par ses billets de soutien, et sa divulgation énumère des indicateurs de compromission pour les équipes de sécurité.

Si votre site web ou votre courriel est hébergé quelque part

Vous ne pouvez probablement pas savoir si votre hébergeur utilise cPGuard, et il n’y a pas lieu de paniquer. Quelques gestes simples aident dans tous les cas :

1. Surveillez un avis de votre hébergeur et suivez-le. S’il mentionne cPGuard ou une réinitialisation de mot de passe, faites-la rapidement.
2. Changez vos mots de passe du panneau de contrôle, FTP et base de données si votre hébergeur vous le demande, avec un mot de passe différent pour chacun.
3. Activez la connexion à deux facteurs pour votre compte d’hébergement.
4. Gardez un œil sur votre site pour repérer des pages, des utilisateurs ou des redirections que vous n’avez pas créés.

Comment Frame peut aider

Cet incident a surtout exposé des secrets de serveur plutôt que des données personnelles, mais si votre courriel figurait dans le portail de facturation d’OPSSHIELD, vous pouvez ajouter cette fuite à une adresse courriel vérifiée dans Frame. Frame montre ce qu’elle a exposé, vous donne une courte liste de vérification et en tient compte dans votre rapport d’exposition. Frame peut aussi chercher vos adresses courriel vérifiées dans la base de données de fuites de Have I Been Pwned. Les alias de courriel de Frame vous permettent aussi de donner à chaque fournisseur sa propre adresse, pour qu’une fuite n’atteigne pas tout. Frame ne recueille ni ne conserve jamais les données divulguées elles-mêmes.

À lire aussi

• Des téléchargements du CLI d’OVHcloud ont été remplacés par un voleur de secrets : un autre cas où un canal de téléchargement de confiance a livré du code malveillant.
• Une version malveillante de LiteLLM a volé des identifiants pendant environ deux heures : comment une version piégée d’un paquet a atteint les développeurs qui lui faisaient confiance.

Sources

• OPSSHIELD, Security Incident Disclosure: manage.opsshield.com (en anglais), 3 novembre 2026
• OPSSHIELD, cPGuard security advisory: Update channel compromise (en anglais), novembre 2026
• BleepingComputer, Hackers hijack cPGuard autoupdate to deploy backdoor, steal data (en anglais), 3 novembre 2026
• Help Net Security, Poisoned cPGuard update hits thousands of web hosting servers (en anglais), 4 novembre 2026
• The Hacker News, cPGuard Update Channel Hijacked to Backdoor Linux Servers and Collect Password Hashes (en anglais), novembre 2026
• SecurityWeek, Malicious cPGuard Updates Served in OpsShield Supply Chain Attack (en anglais), 4 novembre 2026