Un binaire de Control Web Panel doté d’une porte dérobée et un canal de mise à jour de cPGuard détourné sont deux incidents distincts. Voici ce que chacun implique pour les administrateurs d’hébergement.
Deux incidents qui touchent des environnements d’hébergement Linux
Début novembre 2026, des chercheurs et des éditeurs ont révélé deux incidents de sécurité distincts impliquant des outils servant à administrer et à protéger des serveurs d’hébergement Linux. Le 5 novembre, QiAnXin XLab a publié une étude sur CWPdoor, une porte dérobée (backdoor) intégrée à une version modifiée du binaire de serveur web cwpsrv utilisé par Control Web Panel (CWP). Par ailleurs, OPSSHIELD a révélé le 3 novembre qu’un attaquant s’était introduit dans une partie de son infrastructure et avait utilisé le canal de mise à jour de cPGuard pour diffuser une mise à jour malveillante le 2 novembre.
| Incident | Voie d’attaque | Impact sur la sécurité |
|---|---|---|
| CWPdoor | Un script fourni par l’attaquant, qui ressemble à un outil de mise à jour, remplace cwpsrv par un binaire trojanisé | Exécution de commandes à distance dissimulée |
| cPGuard | Des identifiants volés de distribution des mises à jour permettent à une mise à jour malveillante d’atteindre les serveurs des clients | Exécution avec les privilèges root, exposition d’identifiants et persistance |
Ces incidents ne doivent pas être présentés comme une seule campagne ni comme un seul canal de mise à jour compromis. XLab n’a pas établi que l’infrastructure officielle de mise à jour de l’éditeur légitime de CWP ait été compromise. XLab indique ne pas savoir comment le script parvient jusqu’aux serveurs ni quelle vulnérabilité est exploitée. L’incident cPGuard, lui, a impliqué une compromission réelle du mécanisme de distribution d’OPSSHIELD. Ce que les deux ont en commun est d’ordre pratique : tous deux atteignent un serveur par l’intermédiaire d’un logiciel qui s’exécute avec des privilèges élevés. Dans les deux cas, la réponse consiste donc à vérifier le binaire, puis à renouveler tout ce qu’un processus root pouvait lire.
CWPdoor : le serveur web continue de fonctionner tout en dissimulant une porte dérobée
CWP fournit une interface d’administration pour l’hébergement sur serveur. Son composant cwpsrv traite le trafic d’administration. Selon XLab, son Cyber Threat Insight and Analysis System a capturé le 29 juin 2026 un script nommé cwpsrv_update.sh. Ce script télécharge un fichier nommé cwpsrv depuis 136.0.141[.]71 et remplace le fichier du même nom sur le système. XLab indique que le script ne prend en charge que les versions 1.24.0 et 1.15.10 de cwpsrv et qu’il doit s’exécuter en tant que root.
XLab décrit le binaire de remplacement comme une porte dérobée passive. Il se comporte comme un cwpsrv légitime pour les requêtes ordinaires et n’agit que sur une requête qui porte trois en-têtes précis, X-Ngx-Integrity-Time, X-Ngx-Integrity-Data et X-Ngx-Integrity-Sig. Si la vérification de l’horodatage ou de la signature échoue, la requête est traitée comme du trafic ordinaire. XLab indique aussi que la porte dérobée modifie le contexte de module de la requête afin que le module de journalisation ne l’enregistre pas, et que le script restaure les horodatages des fichiers et des répertoires et exécute history -d. C’est une déduction de TechiesJournal, et non une affirmation de XLab : une telle porte dérobée est difficile à détecter au moyen de contrôles de disponibilité, car le panneau continue de fonctionner.
XLab signale également qu’un fichier nommé evidencia.tgz a été envoyé sur VirusTotal depuis le Brésil le 30 septembre 2026. Il contenait un fichier cwpsrv.suspeito que XLab identifie comme CWPdoor, sans aucune détection, à côté d’un échantillon que la plupart des éditeurs antivirus ont identifié comme la porte dérobée Ebury. XLab en conclut qu’il existe de véritables victimes et indique que le lien entre Ebury et CWPdoor n’est pas clair.
Selon les données de QiAnXin Hunter Platform citées par XLab, plus de 340 000 instances CWP étaient exposées sur Internet au cours du mois écoulé (XLab). Ce chiffre mesure une exposition, et non des infections confirmées, et il ne permet pas d’établir combien de systèmes ont reçu le binaire trojanisé.
Source : QiAnXin XLab, CWPdoor.
cPGuard : des mises à jour logicielles de confiance sont devenues la voie de diffusion
La divulgation d’OPSSHIELD du 3 novembre indique qu’un attaquant a pénétré son environnement de facturation et de gestion des licences les 1er et 2 novembre, a dérobé les clés servant à publier les mises à jour et a mis en ligne une fausse mise à jour de cPGuard le 2 novembre. L’éditeur indique que les agents cPGuard l’ont installée entre 02 h 08 et 03 h 20 UTC environ. Ne vous fiez pas à cette plage horaire pour écarter un serveur. Dans les exemples d’entrées de journal de son avis, OPSSHIELD montre des versions concernées installées jusqu’à 12 h 46 le 2 novembre, et précise qu’un journal absent ou incomplet ne démontre pas à lui seul qu’un serveur n’a pas été touché. Il recommande de contacter le support d’OPSSHIELD en cas de doute.
Selon l’éditeur, le script malveillant s’exécutait avec les privilèges root, collectait les empreintes de mots de passe, les clés SSH, les identifiants MySQL et l’historique du shell, et laissait derrière lui un shell root caché ainsi qu’une tâche planifiée. Les deux pages d’OPSSHIELD divergent sur la manière dont l’attaquant s’est introduit. La divulgation indique qu’un compte client enregistré le 1er novembre a permis d’accéder à l’application de facturation et que la requête exacte ne figure pas dans ses journaux. L’avis indique que des identifiants compromis ont été utilisés et que la manière dont ils avaient été obtenus faisait l’objet d’une enquête.
| Observation rapportée par l’éditeur | Ampleur |
|---|---|
| Serveurs clients ayant exécuté la mise à jour malveillante | Environ 2950 |
| Enregistrements de comptes du portail de facturation copiés | Environ 7900 |
| Versions de mise à jour concernées (avis d’OPSSHIELD) | 5.88.12 à 5.88.19 |
OPSSHIELD indique que les mots de passe des comptes de facturation étaient stockés sous forme d’empreintes bcrypt. Ces chiffres sont des constats d’incident rapportés par l’éditeur, et non une confirmation indépendante de ce qui a été exfiltré précisément de chaque serveur. Le nombre de serveurs a par ailleurs évolué : le premier avis d’OPSSHIELD estimait que l’attaquant avait récupéré 32 fichiers collectés et présentait ce chiffre comme un décompte préliminaire des récupérations confirmées, et non comme le nombre de serveurs concernés, tandis que sa divulgation ultérieure indique qu’environ 2950 serveurs ont exécuté la mise à jour.
Sources : divulgation d’incident d’OPSSHIELD (la plus récente) et avis d’OPSSHIELD (premiers constats).
Ce que doivent faire les administrateurs de cPGuard
L’avis d’OPSSHIELD demande d’utiliser cPGuard 5.88.25 ou une version ultérieure. Sa divulgation plus récente désigne 5.88.26 comme la version saine et indique qu’une mise à jour supplémentaire supprime la tâche planifiée i93677. Mettez à jour vers la dernière version, puis vérifiez que les fichiers listés ci-dessous ont disparu. L’avis présente les étapes dans cet ordre.
1. Vérifier l’historique des mises à jour. Une entrée correspondant à une version comprise entre 5.88.12 et 5.88.19 signifie que le serveur a installé une mise à jour concernée. OPSSHIELD précise que cela confirme l’installation, mais pas les fichiers qui ont été transférés, et qu’un tel serveur doit être considéré comme potentiellement compromis même s’il exécute désormais 5.88.25 ou une version ultérieure.
grep 'Successfully updated' /opt/cpguard/logs/install_log2. Mettre à jour.
cpgcli update --start3. Vérifier la version. L’avis d’OPSSHIELD demande la version 5.88.25 ou une version ultérieure et recommande de contacter le support si la mise à jour échoue.
cpgcli --version4. Vérifier que les fichiers résiduels ont disparu. La divulgation cite /etc/cron.d/i93677, /var/tmp/.i93677/ et /var/tmp/.cpg91511_sh. L’avis ajoute /var/tmp/.cpg91511 et /var/tmp/.cpg91511/loot.tgz. OPSSHIELD précise que l’absence de ces fichiers après le nettoyage ne permet pas d’établir si le script s’est exécuté auparavant.
5. Renouveler les identifiants. Une mise à jour saine ne révoque pas les identifiants déjà copiés. OPSSHIELD demande aux administrateurs des serveurs potentiellement concernés de :
- Réinitialiser le mot de passe root et ceux de tous les comptes locaux, depuis un environnement de récupération de confiance selon l’avis, et changer depuis un appareil de confiance les mots de passe réutilisés sur d’autres systèmes.
- Remplacer les clés SSH de root et supprimer les anciennes clés publiques du fichier
authorized_keyssur chaque système qui leur faisait confiance. Considérer les autres serveurs accessibles avec ces clés comme exposés tant que les clés n’ont pas été remplacées. - Changer le mot de passe root de MySQL et les mots de passe de bases de données stockés dans
/root/.my.cnf. - Renouveler les mots de passe, clés d’API et jetons présents dans l’historique du shell de root, ainsi que les clés de
/root/.s3cfget tout jeton DigitalOcean (l’avis cite les deux). - Réinitialiser le mot de passe du portail de facturation d’OPSSHIELD et activer la connexion à deux facteurs. La divulgation demande cette réinitialisation même lorsque cPGuard était hors ligne pendant la période concernée.
- Reconstruire le serveur à partir d’une sauvegarde saine antérieure au 1er novembre uniquement si OPSSHIELD vous a indiqué que l’attaquant s’est connecté manuellement à votre serveur. Dans le cas contraire, l’avis ne recommande pas de reconstruction systématique et qualifie cette évaluation de provisoire.
L’article de TechiesJournal sur ce qui fuit avec une configuration de pare-feu et ce qu’il faut renouveler traite du même problème de renouvellement pour une autre catégorie d’équipements. Son article sur ce qu’il faut faire après la correction d’un équipement exploité explique pourquoi un système corrigé n’est pas forcément un système sain.
Ce que doivent faire les administrateurs de CWP
XLab publie les vérifications suivantes à effectuer sur l’hôte. La première recherche le socket Unix ngx_http_integrity_helper que CWPdoor utilise pour la communication interprocessus.
ss -axp | grep integrity
ps aux | grep cwpsrv
strings /usr/local/cwpsrv/bin/cwpsrv | grep X-Ngx-IntegrityPour la deuxième commande, XLab indique qu’il faut rechercher des processus enfants auxiliaires (helper) suspects de cwpsrv. Pour la troisième, il indique qu’il faut rechercher des chaînes X-Ngx-Integrity suspectes dans le binaire. Les équipes réseau peuvent aussi rechercher dans les journaux du pare-feu et du proxy des connexions vers 136.0.141[.]71, l’adresse que XLab désigne comme celle du téléchargeur.
Si une infection est confirmée, XLab recommande trois étapes. D’abord, remplacer le cwpsrv malveillant par la sauvegarde légitime que le script de l’attaquant a créée dans /usr/local/cwpsrv/bin, nommée cwpsrv.prev- suivi d’un horodatage. Ensuite, passer à la dernière version et vérifier que ss -axp | grep integrity ne renvoie plus aucun résultat. Enfin, renouveler immédiatement tous les identifiants du panneau de contrôle en les considérant comme compromis, considérer l’hôte comme compromis et y rechercher d’autres menaces.
Notez que XLab indique aussi que le script supprime sa sauvegarde lorsque le remplacement réussit, si bien que ce fichier cwpsrv.prev- peut ne pas exister. Par déduction, TechiesJournal estime qu’un binaire obtenu auprès d’une source CWP de confiance est le remplacement le plus sûr. XLab vous demande de considérer l’hôte comme compromis, car la porte dérobée peut exécuter des commandes arbitraires : remplacer le binaire ne suffit donc pas.
Source : QiAnXin XLab, CWPdoor.
Ce que les administrateurs doivent retenir
CWPdoor montre comment un exécutable modifié peut dissimuler un accès à distance dans un logiciel qui semble toujours fonctionner. L’incident cPGuard illustre un danger distinct, celui d’un attaquant qui obtient l’accès à un chemin légitime de distribution des mises à jour. La réponse concrète dépend de l’événement qui a touché l’hôte : vérifier les binaires installés et l’historique des mises à jour, remplacer les composants compromis, rechercher les mécanismes de persistance et renouveler les identifiants exposés.
Références
- QiAnXin XLab: CWPdoor research, 5 novembre 2026
- OPSSHIELD incident disclosure (latest), 3 novembre 2026
- OPSSHIELD advisory (earlier findings), 3 novembre 2026
Sources consultées le 12 novembre 2026. OPSSHIELD indique qu’il continuera de mettre à jour sa divulgation : consultez-la avant d’agir.