CVE-2026-67401 transforme un compte mail cPanel en root via EmailTrack
Le 8 septembre 2026, cPanel a révélé une injection SQL dans EmailTrack qui permet à tout titulaire d’un compte mail d’écrire des fichiers arbitraires puis d’exécuter du code en root. Toutes les versions supportées sont touchées : sur un hébergement mutualisé, chaque compte client devient une porte d’entrée vers le serveur entier.
8 septembre 2026. cPanel publie un avis pour CVE-2026-67401, une injection SQL dans EmailTrack. 9 septembre 2026. L’enregistrement CVE est publié avec un CVSS 9,9 (Critical). Toutes les versions supportées sont touchées. Pourquoi c’est important : la chaîne part d’un simple compte mail et se termine par une exécution de code root sur le serveur entier.
La distance entre un compte mail et root
L’avis de cPanel tient en une phrase qu’il faut lire au mot près : « un titulaire de compte cPanel authentifié disposant de privilèges liés au courrier peut créer des fichiers arbitraires sur le serveur via la fonctionnalité EmailTrack », et « l’exploitation réussie mène à une exécution de code en tant qu’utilisateur root ».
EmailTrack est le sous-système derrière la fonction « Track Delivery », qui permet à un titulaire de compte de consulter les journaux et rapports de livraison de ses propres e-mails, tirés de la base eximstats. L’injection se niche là : en manipulant les paramètres de suivi, l’attaquant fait remonter une requête SQL forgée qui écrit un fichier sur le disque — le classique INTO OUTFILE devenu écriture de fichier arbitraire. De ce fichier, le chemin vers du code exécuté en root est court.
Le vecteur est CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H : exploitable à distance, sans interaction, avec un compte à bas privilège, et un impact qui change de portée — le passage d’un compte à l’hôte entier. La classe CWE-89 (injection SQL) est confirmée. Le crédit de la découverte revient à Ali Mustafa (rz1027) et abed1526.
Toutes les versions supportées sont touchées
Certains avis n’affectent qu’une branche ; celui-ci est différent. La colonne « affecté » dit « toutes les versions supportées », ce qui signifie qu’être à jour n’était pas une protection. La diligence n’a exempté personne : seul le patch après coup comptait.
Les versions corrigées sont v11.110.0.143, v11.134.0.55, v11.136.0.39, v11.138.0.4, et v11.138.1.9 pour la gamme WP2. Un serveur sur la branche 11.136 doit donc être au moins en build 39.
Un détail notable : l’avis de cPanel ne publie ni score CVSS ni niveau de sévérité, ce qui est inhabituel pour un bug dont l’impact annoncé est l’exécution de code root. C’est l’enregistrement CVE, publié le lendemain, qui porte le CVSS 9,9. L’absence de score chez l’éditeur ne change rien à la conclusion : bas privilège en entrée, contrôle total du serveur en sortie.
La chronologie confirme une procédure d’embargo classique : le bug a été réservé le 29 juillet 2026 via le programme de bug bounty, soit environ six semaines avant la publication du 8 septembre. Le temps de l’éditeur a servi à produire les builds corrigés, pas à communiquer.
Techniquement, l’écriture INTO OUTFILE aboutit parce que les requêtes d’EmailTrack s’exécutent avec les privilèges du démon cPanel, bien au-dessus de ceux du compte. C’est cette asymétrie — un compte à bas privilège qui interroge une base avec des privilèges élevés — qui transforme une simple injection SQL en écriture de fichier, puis en exécution root. Les panneaux de contrôle ne sont pas une cible isolée : ils sont le chokepoint multi-tenant, et une seule faille y vaut des centaines de sites.
Le mutualisé transforme la menace
Sur un serveur mono-tenant, exiger un compte authentifié est une vraie barrière : les seules personnes qui peuvent amorcer la chaîne sont celles que vous contrôlez déjà.
Sur un hébergement mutualisé ou revendeur, cette barrière disparaît. Chaque client de la machine détient déjà un compte mail, puisque c’est ce qu’il a acheté. La question n’est donc plus « un attaquant peut-il obtenir un compte », mais « les plusieurs centaines de comptes de ce serveur — et tous ceux qui ont réutilisé l’un de ces mots de passe ailleurs — sont-ils tous dignes de confiance et non compromis ». Un seul mot de passe faible, sur un seul site sans rapport, fournit toute la chaîne.
C’est le point à méditer pour quiconque héberge une boutique Magento ou WordPress sur du mutualisé : la sécurité de votre site n’est pas fonction de votre seule diligence, mais de celle du locataire le moins prudent sur la même machine. La compromission d’un compte voisin donne le root de l’hôte, et donc votre site.
Comment vérifier et patcher
La première action est de connaître le numéro de build exact, pas une assurance générale.
# En root : afficher la version cPanel en cours
/usr/local/cpanel/cpanel -VComparez le résultat aux builds corrigés de votre branche. Sans accès shell, WHM affiche la version en cours sur son écran d’accueil. Sur du mutualisé, demandez à votre hébergeur le numéro de build et l’heure d’application, pas un simple « c’est patché ».
Ensuite, cherchez ce que le bug fait réellement : écrire des fichiers. Tout fichier inattendu et récemment créé sous un chemin accessible au web mérite une inspection — c’est le réflexe déjà recommandé lors du balayage StyleSmuggler. L’arbitraire d’écriture est le mécanisme ici, donc l’indicateur de compromission est un fichier qui ne devrait pas exister.
Ce qu’il faut chercher dans les journaux
Comme l’injection aboutit à une écriture de fichier arbitraire, l’indicateur de compromission n’est pas une connexion anormale mais un fichier qui ne devrait pas exister. Les premières cibles d’une écriture INTO OUTFILE sont les chemins servis par le web : public_html, les répertoires de thèmes, ou un .php déposé dans un dossier de cache.
Concrètement, cherchez les fichiers créés ou modifiés après le 8 septembre dans les arborescences web, les binaires setuid inhabituels, et toute tâche cron nouvellement ajoutée par un compte cPanel. La base eximstats elle-même peut porter des traces de la requête forgée dans ses journaux de requêtes. Si le serveur est mutualisé, l’audit doit couvrir tous les comptes, pas seulement le vôtre : l’attaquant n’a besoin que du compte le plus faible pour atteindre le root de l’hôte.
Verdict
CVE-2026-67401 est un cas d’école de ce que signifie un bloc de confiance mutualisé : la frontière de sécurité entre locataires vaut ce que vaut le compte le plus faible.
Si vous administrez un serveur cPanel, vérifiez le build maintenant, appliquez le patch, puis auditez les fichiers récemment écrits sous les chemins web. Si vous êtes sur un hébergement mutualisé, exigez le numéro de build et l’heure d’application de votre hébergeur, et traitez le silence comme une information sur la façon dont la prochaine faille sera gérée. Et si vous hébergez un commerce en ligne, rappelez-vous que la confiance dans votre plateforme s’arrête là où commence le compte le moins prudent du même serveur.