Control Web Panel : une porte dérobée cachée dans le serveur web du panneau exécute les commandes d'un attaquant

Ce qui s'est passé

Le 6 novembre 2026, des chercheurs ont signalé une porte dérobée cachée dans le serveur web de Control Web Panel (CWP), un panneau d'hébergement pour serveurs Linux. Cette porte dérobée exécute les commandes que les attaquants envoient par des requêtes web, et elle le fait sans laisser d'entrées dans les journaux d'accès. Il est donc difficile de la repérer lors d'une analyse habituelle des journaux.

Il ne s'agit pas d'une vulnérabilité qui peut être corrigée par un correctif. L'installation de la porte dérobée nécessite un accès root : tout serveur sur lequel elle est découverte a donc déjà été entièrement compromis. Elle sert à conserver cet accès et à exécuter ultérieurement d'autres commandes.

Qui est concerné

Sont exposés les exploitants de serveurs Linux qui utilisent Control Web Panel, en particulier les hébergeurs et les agences qui gèrent des serveurs CWP pour leurs clients. Un serveur ne contient la porte dérobée que si un attaquant a déjà obtenu les droits root sur celui-ci. Le rapport source ne précise pas comment les attaquants ont obtenu ces droits root, il est donc recommandé de vérifier chaque serveur CWP.

Que faire maintenant

1. Assurez-vous que Control Web Panel et le système d'exploitation sont entièrement à jour, afin que les faiblesses connues ne puissent pas être utilisées pour regagner l'accès.
2. Restreignez l'accès à l'interface web du panneau : autorisez-le uniquement depuis des adresses IP de confiance, via le pare-feu ou un VPN, et ne l'exposez pas à l'ensemble d'internet.
3. Vérifiez chaque serveur CWP comme décrit dans la section suivante. Comme la porte dérobée n'écrit pas d'entrées dans les journaux d'accès, ne vous fiez pas uniquement aux journaux du serveur web.
4. Si vous repérez des signes de compromission, considérez le serveur comme non fiable. Conservez une copie des éléments de preuve, puis reconstruisez le serveur à partir d'une installation propre et ne restaurez que les données (sites web, bases de données, messagerie), et non les fichiers système ni les binaires, à partir de sauvegardes réalisées avant la compromission.
5. Après une compromission, modifiez tous les identifiants stockés sur le serveur ou utilisés avec celui-ci : mots de passe root et utilisateurs, clés SSH, comptes du panneau, mots de passe des bases de données, comptes de messagerie et clés API. Informez les clients concernés lorsque cela est requis.
6. Examinez les sauvegardes et les autres serveurs qui partagent des identifiants ou des clés SSH avec une machine touchée, car un attaquant disposant des droits root a pu se déplacer vers d'autres systèmes.

Comment vérifier si vous êtes concerné

Le rapport ne publie pas de noms de fichiers ni d'indicateurs précis. Vérifiez donc les points suivants sur chaque serveur CWP et comparez avec les recommandations du fournisseur indiquées ci-dessous :

• Vérifiez l'intégrité des paquets installés et des binaires système, par exemple avec rpm -Va sur les systèmes basés sur RHEL, et recherchez les fichiers modifiés appartenant au serveur web du panneau ou aux outils système essentiels.
• Comparez les fichiers du serveur web du panneau avec ceux d'un serveur CWP fraîchement installé, de la même version et connu comme sain, ou avec les sommes de contrôle fournies par l'éditeur lorsqu'elles sont disponibles.
• Recherchez les processus inattendus lancés par le serveur web du panneau ainsi que les connexions réseau sortantes inhabituelles (ps auxf, ss -tunap).
• Examinez les journaux d'authentification à la recherche de connexions root ou d'accès SSH provenant d'adresses inconnues, et vérifiez /root/.ssh/authorized_keys ainsi que les clés des autres utilisateurs pour détecter des entrées que vous n'avez pas ajoutées.
• Vérifiez les crontabs, les unités systemd et les autres emplacements de démarrage pour des entrées que vous ne reconnaissez pas.
• Si vous utilisez une supervision externe du trafic sortant ou de l'intégrité des fichiers, examinez-la pour détecter les modifications survenues depuis la dernière date à laquelle le serveur était considéré comme sain.

Si vous ne pouvez pas écarter avec certitude une compromission, la reconstruction du serveur est le choix le plus sûr, car un attaquant disposant des droits root peut dissimuler ses traces dans le système lui-même.

Sources

• https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• https://thehackernews.com/2026/11/hackers-hide-linux-backdoor-in-control.html