Une nouvelle faille cPanel permet à un simple compte de messagerie hébergé d’obtenir une exécution de code root sur le serveur. Référencée CVE-2026-67401, elle touche toutes les versions supportées et transforme le moindre compte client en prise de contrôle totale de la machine mutualisée. Pour une PME ou une ETI qui héberge son site, sa boutique ou ses boîtes mail chez un prestataire cPanel, l’enjeu n’est pas théorique : votre voisin de palier peut devenir administrateur de votre serveur. Ce tutoriel détaille les vérifications et les actions concrètes à mener dès aujourd’hui.
Comprendre la faille cPanel CVE-2026-67401
cPanel/WHM est le panneau d’administration le plus répandu chez les hébergeurs mutualisés et sur les VPS d’entreprise. Il orchestre Apache, Exim, Dovecot, MySQL et les comptes utilisateurs d’un même serveur. Cette centralisation est précisément ce qui rend la faille cPanel dangereuse : un composant privilégié accepte une entrée fournie par un compte à privilèges de messagerie et l’exécute avec les droits du système.
Le scénario d’attaque est direct :
- l’attaquant obtient un accès à un compte mail hébergé — par phishing, réutilisation de mot de passe ou achat de journaux d’infostealer ;
- il exploite le composant vulnérable pour faire exécuter sa charge avec les privilèges root ;
- il accède alors à tous les comptes du serveur : fichiers, bases de données, sauvegardes, certificats et identifiants stockés.
Autrement dit, la barrière entre locataires d’un même hébergement mutualisé disparaît. Sur un serveur qui héberge trente sites clients, une seule boîte mail compromise suffit.
Qui est concerné
Toutes les branches supportées de cPanel & WHM sont impactées et des correctifs sont disponibles. Sont exposés :
- les serveurs mutualisés gérés par un hébergeur tiers ;
- les VPS et serveurs dédiés sur lesquels votre équipe a installé cPanel/WHM ;
- les revendeurs qui hébergent leurs propres clients.
Tutoriel : sécuriser votre hébergement contre la faille cPanel
Étape 1 — Identifier votre version
Connectez-vous en SSH sur le serveur et relevez la version exacte :
/usr/local/cpanel/cpanel -Vaffiche la version installée ;- dans WHM, la version figure en haut à droite de l’interface ;
- si vous êtes en mutualisé sans accès SSH, la version apparaît généralement en pied de page de votre espace client.
Notez cette valeur : c’est elle qui déterminera si votre serveur est déjà corrigé ou non.
Étape 2 — Appliquer le correctif sans attendre
Sur un serveur que vous administrez, lancez la mise à jour :
/scripts/upcp --forcepour forcer la mise à jour de cPanel & WHM ;- vérifiez ensuite la version avec
/usr/local/cpanel/cpanel -V; - activez les mises à jour automatiques dans WHM (Server Configuration > Update Preferences), en branche Release ou Stable, jamais en mode manuel.
Si votre hébergement est infogéré, n’attendez pas la newsletter du prestataire. Ouvrez un ticket nommant explicitement la CVE-2026-67401 et demandez une date de déploiement écrite. Un hébergeur incapable de répondre sous 24 heures sur une escalade root est une information en soi.
Étape 3 — Chasser les comptes de messagerie compromis
Le point d’entrée de l’attaque est un compte mail. C’est donc là que se joue la prévention :
- listez les comptes mail inactifs depuis plus de six mois et supprimez-les ;
- forcez une rotation des mots de passe sur l’ensemble des boîtes du domaine ;
- bloquez les authentifications réussies depuis des pays où vous n’avez aucun collaborateur ;
- inspectez
/var/log/exim_mainloget les journaux Dovecot à la recherche de connexions inhabituelles.
Étape 4 — Vérifier l’absence de persistance
Si le serveur a pu être exploité avant le correctif, la mise à jour ne suffit pas. Contrôlez :
- les tâches cron de tous les utilisateurs (
ls -la /var/spool/cron/) ; - les clés SSH ajoutées dans
~/.ssh/authorized_keysde chaque compte, y compris root ; - les comptes WHM créés récemment et les revendeurs inconnus ;
- les binaires SUID inattendus, via
find / -perm -4000 -type ffiltré sur les fichiers récents.
Étape 5 — Réduire la surface pour la prochaine fois
Une faille cPanel reviendra : le panneau concentre trop de privilèges pour ne jamais être visé. Réduisez durablement l’exposition :
- restreignez l’accès aux ports WHM (2087) et cPanel (2083) à vos adresses IP d’administration ou à un VPN ;
- activez l’authentification à deux facteurs sur WHM et sur les comptes cPanel ;
- séparez les activités critiques (boutique, ERP, messagerie) sur des serveurs distincts plutôt que sur un mutualisé unique ;
- externalisez les sauvegardes hors du serveur : une sauvegarde stockée sur la machine compromise ne vaut rien.
Ce que cette faille cPanel dit de votre chaîne d’hébergement
L’incident illustre un angle mort classique des PME-ETI : la sécurité du serveur mutualisé est perçue comme le problème de l’hébergeur, alors que les données exposées sont les vôtres. La faille cPanel ne se corrige pas seulement par un correctif, mais par une capacité à savoir, en quelques minutes, quelles versions tournent, quels comptes existent et qui peut atteindre l’interface d’administration. La même logique s’applique aux arbitrages de priorisation des correctifs et à la sécurisation des consoles d’administration à distance.
Traitez donc la CVE-2026-67401 comme un test de votre chaîne d’hébergement : patchez, purgez les comptes mail dormants, fermez les interfaces d’administration à l’Internet public, et exigez de votre prestataire un engagement de délai. Une escalade vers root depuis un simple compte de messagerie ne laisse aucune marge de tolérance.