CWP2Shell : une chaîne de dix failles donne root sur plus de 118 000 panneaux Control Web Panel
Le 3 novembre 2026, VulnCheck révèle dix vulnérabilités dans Control Web Panel (CWP) qui, enchaînées, mènent d’une requête non authentifiée à un shell root, alors que 118 000 instances sont repérées en ligne. Les hébergeurs doivent passer en version 1.29 et retirer les ports 2083, 2031 et 2087 de l’Internet public.
3 novembre 2026. VulnCheck publie une divulgation de dix vulnérabilités dans Control Web Panel (CWP), le panneau d’hébergement autrefois appelé CentOS Web Panel, sous le titre « CWP2Shell: The Login Page That Never Says No ». 3 novembre 2026, même jour. L’auteur, Valentin Lobstein (Chocapikk), documente une chaîne complète : une requête non authentifiée atteint l’exécution de code, puis deux chemins indépendants mènent à un shell root. 3 novembre 2026, encore. VulnCheck Target Intelligence compte 118 151 observations de service CWP, dont 19 834 sur le seul port 2083 du panneau utilisateur. L’essentiel tient en une phrase : la porte d’un panneau de contrôle, censée dire « non », continue de travailler après avoir répondu.
Pour un hébergeur qui fait tourner des dizaines de sites clients derrière un panneau unique, ce n’est pas une CVE de plus. C’est la démonstration que la frontière entre un utilisateur à faible privilège et des actions de super-utilisateur ne tenait qu’à un mot-clé manquant.
Le point d’entrée : une redirection qui n’arrête rien
CWP expose son panneau utilisateur sur le port 2083. La page de connexion, partagée par tous les comptes, renvoie une redirection 302 vers l’écran de login quand on demande un tableau de bord sans être authentifié. Le défaut est là : derrière cette redirection, il manque un exit(). La requête « tombe à travers » et inclut un module dont le nom est contrôlé par l’attaquant.
Un module est ici une simple page PHP du panneau — l’éditeur php.ini, le gestionnaire de fichiers — que le tableau de bord charge par son nom pour afficher une section. CVE-2026-73695, la faille d’ouverture, est une inclusion de fichier local non authentifiée via une traversée de chemin sur le paramètre module (CWE-98). CVE-2026-73696 décrit l’exécution après redirection elle-même (CWE-698). Une fois le module atteint, deux couvercles se soulèvent : CVE-2026-73697 écrit un fichier arbitraire et injecte une commande via phpini_editor, et CVE-2026-77876 injecte une commande dans le module protected_directory (CWE-78), le binaire qui passe l’entrée directement dans shell_exec.
À ce stade, l’attaquant exécute du code en tant qu’utilisateur d’hébergement. C’est l’entrée. L’escalade vient ensuite.
L’escalade : une API root sur la boucle locale
CWP fait tourner un petit service nommé user API sur 127.0.0.1:2302, en tant que root, qui dialogue avec MySQL en root@localhost. Il est censé être protégé par une frontière de jeton. Deux brèches la contournent.
- CVE-2026-77877 : l’application de jeton manque sur plusieurs routes de l’API racine — des routes restent joignables sans authentification (CWE-306).
- CVE-2026-77879 : une injection SQL dans la porte
access_token()forge l’authentification (CWE-89).
Derrière ces deux brèches, trois injections de commande tournent en root : CVE-2026-77878 sur /v1/restoredatabase/, CVE-2026-77880 sur /v1/newpass/, et CVE-2026-104080 sur /v1/valid_token/, où la valeur brute user atteint une commande grep appartenant à root. CVE-2026-77881, une injection SQL aveugle sur /v1/user_panel_dashboard/, lit la base entière en MySQL root.
Enchaînées, une seule adresse et un nom de compte d’hébergement donnent un shell root — CVSS 10.0 une fois le changement de périmètre compté. VulnCheck a validé la chaîne sur un build CWP7 webpanel 1.8 sous AlmaLinux 9, un build qui corrigeait pourtant déjà l’ancienne faille CVE-2025-48703.
Une récidive, pas une nouveauté
CWP non authentifié vers RCE n’est pas une catégorie inédite. CVE-2025-48703, une injection de commande dans le module filemanager, avait été signalée comme exploitée par VulnCheck KEV le 15 août 2025, puis massivement exploitée quelques jours après la sortie d’un exploit public, avant d’atteindre CISA KEV le 4 novembre 2025. Le mécanisme était le même : le dispatch du panneau atteint un module avant toute authentification, et ce module exécute une entrée de requête dans un shell.
L’ironie est précise : le build 1.8 testé renvoie bien un 403 à l’exploit public de 48703, et exécute quand même une commande par le module d’à côté. Le correctif précédent était ponctuel ; la classe de bug, elle, est restée.
Ce qu’il faut faire maintenant
Le correctif existe : les dix failles sont fermées dans CWP 1.29, publié le 31 octobre 2026, par étapes — 1.12 ferme l’entrée pré-auth, 1.16 les modules du panneau utilisateur, 1.27 et 1.29 l’API racine. La version courante recommandée est 1.30.
- Passer en 1.29 ou plus. C’est la seule action qui ferme la chaîne complète. Vérifiez la version réelle de chaque panneau, pas seulement le changelog.
- Retirer les ports du panneau de l’Internet. Gardez 2083 (utilisateur), 2031 et 2087 (admin) derrière une liste d’autorisation ou un VPN. Même corrigé, un panneau de contrôle n’a pas à être public.
- Auditer les comptes d’hébergement. Un seul nom de compte valide suffit à l’entrée sur les builds antérieurs à 1.12 ; passez en revue les comptes et leurs accès.
- Surveiller la boucle locale. Toute requête anormale vers le service sur
127.0.0.1:2302est un signal d’escalade en cours.
La mise à jour n’est pas une option : sur un build antérieur à 1.12, un seul nom de compte suffit à atteindre root sans authentification.
Verdict
La faille n’est pas une ligne de code maladroite ; c’est une frontière d’authentification réduite à un mot-clé manquant, répliquée entre le panneau utilisateur et l’API racine. Si vous exploitez un panneau CWP, passez en 1.29 ou 1.30 immédiatement et coupez les ports 2083/2031/2087 d’Internet — le volume d’exposition, plus de 118 000 instances, garantit que l’exploitation automatisée suivra la divulgation. Si vous hébergez pour des tiers, la leçon est plus large : un panneau de contrôle est une machine à exécuter des actions privilégiées pour le compte d’utilisateurs peu privilégiés, et toute brèche dans sa frontière bascule chaque primitive du mauvais côté d’un coup. La question n’est pas de savoir si ces panneaux seront attaqués, mais combien d’entre eux diront encore « non » sans s’arrêter.