cPGuard : un canal de mise à jour piraté a installé une porte dérobée sur près de 2 950 serveurs Linux

OPSSHIELD, l’éditeur de la suite de sécurité cPGuard, indique qu’un attaquant a pénétré son serveur de facturation puis publié une fausse mise à jour avec une clé volée, le 2 novembre 2026. Pendant environ 70 minutes, le script s’est exécuté en root sur des serveurs Linux clients, y a déposé un shell caché et a aspiré empreintes de mots de passe, clés SSH et identifiants de bases de données.

Ce qui s’est passé

OPSSHIELD édite cPGuard, une suite de sécurité (antimalware, pare-feu, pare-feu applicatif web) installée sur des serveurs Linux d’hébergement web. Le 3 novembre 2026, l’éditeur a reconnu que son canal de mise à jour avait été détourné. Selon son rapport d’incident, l’attaquant a ouvert le 1er novembre un compte client sous une fausse identité, commandé une licence d’essai gratuite, puis exploité une faille de l’application de facturation pour exécuter des commandes sur le serveur de facturation et de licences. De là, une clé d’accès dérobée lui a permis de déposer une fausse mise à jour de cPGuard dans l’espace de distribution, le 2 novembre peu après 2 h UTC.

Qui est touché

Les agents cPGuard ont installé ce faux paquet entre 2 h 08 et 3 h 20 UTC le 2 novembre, soit une fenêtre d’environ 70 minutes. Lancé en root, le script a déposé un shell caché et envoyé à l’attaquant des fichiers sensibles : /etc/shadow et /etc/passwd, les clés SSH de root, authorized_keys et known_hosts, le mot de passe root MySQL de /root/.my.cnf, l’historique du shell root et, sur quelques serveurs, les clés S3 de /root/.s3cfg. OPSSHIELD estime à environ 2 950 le nombre de serveurs clients concernés. Les données d’environ 7 900 comptes du portail de facturation (nom, société, adresse postale, e-mail, empreintes bcrypt des mots de passe) ont aussi été exposées. L’avis cite les versions 5.88.12 à 5.88.19.

Que faire maintenant

1. Mettez à jour chaque serveur avec cpgcli update --start, puis vérifiez avec cpgcli --version : l’éditeur exige au moins la 5.88.25, et la 5.88.26 révoque en plus ses accès de support.
2. Contrôlez l’historique avec grep 'Successfully updated' /opt/cpguard/logs/install_log. Une version comprise entre 5.88.12 et 5.88.19, ou un cPGuard actif pendant la fenêtre, impose de considérer le serveur comme compromis.
3. Cherchez et supprimez /var/tmp/.cpg91511_sh, /var/tmp/.cpg91511/, /etc/cron.d/i93677 et /var/tmp/.i93677/, et recherchez l’adresse IP 94.183.188.91 dans vos journaux.
4. Changez le mot de passe root et ceux de tous les comptes locaux, ainsi que tout mot de passe réutilisé ailleurs.
5. Remplacez les clés SSH de root, retirez les anciennes clés publiques de tous les serveurs qui leur faisaient confiance et passez en revue authorized_keys.
6. Renouvelez les mots de passe MySQL et des bases, les clés S3 et tout jeton ou secret présent dans l’historique du shell root.
7. Modifiez votre mot de passe du portail OPSSHIELD et activez la double authentification, même si vos serveurs n’ont pas été exposés.
8. En cas de traces d’accès manuel, reconstruisez le serveur à partir d’une sauvegarde antérieure au 1er novembre.

Notre avis

Un agent de sécurité qui se met à jour en root ouvre une porte directe sur chaque serveur qu’il protège : l’infrastructure de son éditeur fait alors partie de votre surface d’attaque. Recensez ces agents, sachez d’où viennent leurs mises à jour et ne laissez pas traîner de secrets dans l’historique du shell ou dans des fichiers de root qu’un seul script peut ramasser.

Sources

• OPSSHIELD — cPGuard security advisory: update channel compromise
• OPSSHIELD — Security incident disclosure
• OPSSHIELD — cPGuard changelog
• The Hacker News — cPGuard Update Channel Hijacked to Backdoor Linux Servers and Collect Password Hashes

Comment nous choisissons, vérifions et rédigeons nos analyses →