CVE-2026-41940 : le contournement d'authentification critique de cPanel et WHM et ce que les clients d'hébergement doivent savoir

Le 28 avril 2026, cPanel a publié une mise à jour de sécurité d'urgence pour une vulnérabilité dans cPanel et WHM qui était activement exploitée dans la nature depuis au moins fin février 2026. La vulnérabilité, CVE-2026-41940, est un contournement d'authentification de gravité critique qui permet à un attaquant de prendre le contrôle d'un serveur cPanel à distance sans aucune information d'identification. Un exploit fonctionnel est disponible publiquement, le bogue a été utilisé dans des attaques réelles pendant plus de deux mois, et environ 1,5 million de serveurs cPanel sont visibles sur l'internet public selon la télémétrie standard des moteurs de recherche.

Si vous êtes client d'un cPanel géré chez Gotekky, votre serveur a déjà été corrigé. Nous avons déployé la mise à jour sur notre infrastructure dans les heures suivant la publication par cPanel et avons vérifié qu'aucune compromission de session ne s'était produite sur les serveurs gérés pendant la fenêtre d'exposition. Le reste de ce guide explique ce qu'est la vulnérabilité, comment elle a été exploitée, ce que Gotekky a fait et ce que vous devriez faire si vous exploitez des serveurs cPanel auto-gérés ailleurs.

Ce qu'est réellement CVE-2026-41940

cPanel et WHM partagent un seul démon exposé à internet appelé cpsrvd qui gère les six points de terminaison HTTP et HTTPS de cPanel : l'interface utilisateur cPanel sur les ports 2082 et 2083, l'interface administrateur WHM sur les ports 2086 et 2087, et Webmail sur les ports 2095 et 2096. La vulnérabilité réside dans la partie de cpsrvd qui crée et sauvegarde les fichiers de session avant que l'authentification soit terminée. En envoyant un en-tête d'authentification HTTP Basic spécialement conçu contenant des caractères de saut de ligne dans le champ mot de passe, un attaquant peut injecter de fausses données de session dans le fichier de session sur disque. Quand cette session est rechargée, des valeurs contrôlées par l'attaquant comme user=root et tfa_verified=1 promeuvent ce qui aurait dû être une tentative de connexion échouée en une session root pleinement authentifiée, contournant même l'authentification à deux facteurs.

La catégorie technique est CWE-306, authentification manquante pour une fonction critique, exprimée comme une injection CRLF. Le score CVSS v3.1 est de 9,8 sur 10. L'attaque ne nécessite pas d'authentification, ne nécessite aucune interaction de l'utilisateur et fonctionne contre toute instance cPanel ou WHM joignable sur ses ports standard. La base de code contenait un assistant de désinfection qui aurait empêché l'injection, mais il n'était pas invoqué au point pertinent du code. Le correctif intègre cet assistant directement dans le code de sauvegarde de session pour que la vulnérabilité ne puisse pas se reproduire.

Combien de temps cela a été un zero-day dans la nature

Selon KnownHost et d'autres opérateurs d'hébergement majeurs, l'exploitation contre les serveurs cPanel a été confirmée à partir du 23 février 2026, plus de deux mois avant l'avis et le correctif cPanel du 28 avril. La chronologie de divulgation est contestée : selon les rapports publiés, des chercheurs en sécurité ont signalé le bogue à cPanel environ deux semaines avant l'avis public, et la réponse initiale de cPanel indiquait que le problème n'était pas une vulnérabilité. Le correctif a finalement été publié comme une mise à jour d'urgence sur toutes les versions prises en charge le 28 avril avec un CVE public le même jour.

Cela signifie que tout serveur cPanel qui était joignable sur les ports cPanel standard entre fin février et le 28 avril doit être traité comme potentiellement compromis. L'exploitation n'était pas théorique. Elle se produisait, contre des serveurs réels, pendant deux mois.

Ce que Gotekky a fait et ce que les clients gérés doivent savoir

Nous avons déployé le correctif cPanel sur chaque serveur géré dans notre infrastructure de Toronto dans les heures suivant la publication du 28 avril. Nous avons forcé l'exécution de upcp sur chaque nœud, vérifié que les numéros de version correspondaient aux versions corrigées publiées par cPanel, redémarré cpsrvd et exécuté le script de détection publié par cPanel contre le stockage de session sur chaque serveur. Aucun serveur Gotekky géré dans notre infrastructure n'a montré de preuve de compromission de session pendant la fenêtre d'exposition. Les comptes clients n'ont pas été affectés.

Pour les clients sur des plans gérés par Gotekky, aucune action n'est requise. Le correctif est appliqué. Le script de détection est revenu sans signalement. Vos sessions et identifiants ne faisaient pas partie de la population à risque.

Nous avons aussi profité de l'occasion pour appliquer deux mises à jour de sécurité cPanel supplémentaires qui ont été publiées dans le même cycle de correctifs (décrites ci-dessous), donc les clients gérés sont maintenant à jour sur l'ensemble du round de correctifs de l'écosystème cPanel, pas seulement le CVE.

Les numéros de version corrigés de cPanel et WHM

Si vous exploitez des serveurs cPanel auto-gérés, les versions corrigées dont vous avez besoin sont :

• 11.86 (héritage) : 11.86.0.41
• 11.110 (LTS) : 11.110.0.97
• 11.118 : 11.118.0.63
• 11.126 : 11.126.0.54
• 11.130 : 11.130.0.19
• 11.132 : 11.132.0.29
• 11.134 : 11.134.0.20
• 11.136 (actuelle) : 11.136.0.5
• WP Squared : 136.1.7

Toute version de cPanel plus ancienne que 11.86 est en fin de vie, ne recevra pas de correctif et doit être migrée. Si vous exécutez une telle version, traitez le serveur comme compromis et reconstruisez sur une version actuelle.

Si vous exploitez des serveurs cPanel auto-gérés, faites ceci aujourd'hui

Étape une : mettez à jour immédiatement. Exécutez /scripts/upcp --force en tant que root. Cela force une mise à jour immédiate à travers le flux de mise à niveau normal de cPanel, en ignorant tout délai planifié. Vérifiez le numéro de version avec /usr/local/cpanel/cpanel -V. Redémarrez cpsrvd avec /scripts/restartsrv_cpsrvd.

Étape deux : exécutez le script de détection officiel de cPanel. Le script vérifie /var/cpanel/sessions/ pour les marqueurs spécifiques qui indiquent une exploitation : fichiers de session contenant à la fois token_denied et cp_security_token, sessions pré-authentification portant des attributs authentifiés comme hasroot=1, sessions avec tfa_verified qui manquent de marqueurs d'origine légitimes et valeurs pass= sur plusieurs lignes. Si l'un de ceux-ci est signalé, vous avez la preuve d'une tentative d'exploitation ou d'une exploitation réussie.

Étape trois : si le script de détection signale une compromission, ou si vous ne pouvez pas exclure une exploitation pendant la fenêtre d'exposition, faites tourner chaque identifiant. Cela signifie le mot de passe root, chaque mot de passe d'utilisateur WHM, les mots de passe MySQL, les mots de passe FTP, les mots de passe des comptes courriel pour chaque client et tous les jetons d'API. Auditez /var/log/wtmp et les journaux d'accès WHM pour des connexions inattendues. Vérifiez la persistance : entrées cron que vous n'avez pas créées, authorized_keys SSH que vous n'avez pas ajoutées, fichiers .bashrc modifiés, comptes WHM inconnus et fichiers wp-config.php modifiés sur les sites WordPress hébergés. Traitez le serveur comme non fiable jusqu'à ce que vous ayez complété un audit complet.

Si vous ne pouvez pas appliquer le correctif dans les prochaines heures pour des raisons de contrôle des changements, le contournement consiste à mettre les ports cpsrvd (2082, 2083, 2086, 2087, 2095, 2096) derrière un pare-feu pour qu'ils ne soient joignables que depuis vos plages d'IP d'administration, et à arrêter cpsrvd entièrement avec /scripts/restartsrv_cpsrvd --stop. L'authentification à deux facteurs sur WHM ne bloque pas cette attaque à elle seule, car l'exploit injecte tfa_verified=1 directement dans le fichier de session.

Deux correctifs cPanel supplémentaires publiés la même semaine

Parallèlement à la publication de CVE-2026-41940, cPanel a publié deux autres mises à jour de sécurité qui affectent presque tous les serveurs cPanel. Les clients Gotekky gérés ont reçu les deux dans la même fenêtre de maintenance. Si vous gérez vous-même, ces mises à jour valent la peine d'être appliquées.

Mise à jour EasyApache 4 vers v25.57. Le paquet ea-apache24 a été mis à jour de la version 2.4.66 à 2.4.67, traitant 11 CVE Apache HTTP Server. Le plus significatif est CVE-2026-23918, une faille d'exécution de code à distance dans mod_http2 avec un CVSS de 8,8. mod_http2 n'est pas activé par défaut mais est couramment activé sur les serveurs cPanel exécutant des configurations HTTP/2 modernes, ce qui rend ceci fonctionnellement quasi-universel. CVE-2026-24072 affecte mod_rewrite, qui fait partie de la version Apache de base et est activé par défaut sur tous les serveurs cPanel. Les neuf CVE restants vont de modéré à faible et s'appliquent variablement selon les modules chargés. Appliquez via le processus standard de mise à jour des paquets EasyApache 4 dans WHM, ou via la ligne de commande. Aucun changement de configuration ni temps d'arrêt n'est requis. La publication couvre CentOS 7, AlmaLinux 9 et Ubuntu 20.04, 22.04 et 24.04.

Mise à jour Exim 4.99.2. Quatre CVE Exim ont été traités dans cette mise à jour, le plus critique étant CVE-2026-40685 avec une note CVSS amont de 9,8 (critique) et CVE-2026-40684 à 7,5 (élevé). Appliquez via le mécanisme de mise à jour cPanel standard. Aucun changement de configuration n'est requis.

Au moment de la rédaction, les CVE EasyApache et Exim n'ont pas d'exploits actifs connus, mais l'équipe de sécurité cPanel les publie de façon proactive. Les deux mises à jour sont expédiées via les mécanismes de mise à jour cPanel standard, donc tout serveur avec les mises à jour automatiques activées et non épinglé à une version recevra ceci au prochain cycle de mise à jour sans intervention.

Pourquoi cela importe encore plus en combinaison avec le CVE du noyau Linux cette semaine

CVE-2026-41940 accorde à un attaquant une session WHM root authentifiée à distance, mais il ne lui donne pas seul l'accès shell à l'hôte Linux sous-jacent. Cette distinction importe moins qu'il n'y paraît, car une fois que vous avez WHM root, vous avez la capacité de créer des utilisateurs cPanel, de modifier la configuration, de déployer du code personnalisé et de planifier des tâches cron qui s'exécutent sous ces utilisateurs.

Le problème plus difficile est la combinaison avec deux vulnérabilités du noyau Linux divulguées dans la même fenêtre : CVE-2026-31431 (Copy Fail) le 29 avril et la famille Dirty Frag (CVE-2026-43284 et CVE-2026-43500) le 7 mai. Les deux permettent à tout utilisateur local sur un serveur Linux d'escalader vers root en quelques secondes, et ce sont des problèmes distincts qui nécessitent des atténuations distinctes. Combinée avec le bogue cPanel, la chaîne ressemble à ceci : un attaquant exploite CVE-2026-41940 pour entrer dans WHM sans identifiants, crée un utilisateur cPanel avec accès shell et exécute immédiatement Copy Fail ou Dirty Frag pour prendre le contrôle de l'hôte Linux sous-jacent en tant que root. Corriger cPanel sans aussi traiter les deux vulnérabilités du noyau laisse vos serveurs vulnérables à cette chaîne exacte.

Gotekky a appliqué le correctif cPanel et les deux atténuations du noyau sur tous les serveurs gérés. Nous avons des guides séparés sur Copy Fail (CVE-2026-31431) et Dirty Frag (CVE-2026-43284 et CVE-2026-43500) couvrant le côté noyau en détail. Si vous exploitez des serveurs cPanel auto-gérés, traitez les trois comme une seule réponse d'urgence et appliquez-les cette semaine.

Conseils d'audit et de rotation des identifiants pour la fenêtre d'exposition

Si votre serveur cPanel était joignable depuis internet entre le 23 février et le 28 avril 2026, la posture conservatrice est de supposer que la fenêtre de contournement d'authentification a pu être utilisée contre vous, même si le script de détection revient sans signalement. Le script de détection attrape les schémas d'exploitation les plus courants mais ne peut pas prouver qu'un serveur n'a pas été exploité. Spécifiquement, vous devriez faire tourner WHM root et chaque mot de passe de compte administrateur, faire tourner chaque mot de passe de compte utilisateur cPanel, faire tourner les mots de passe de base de données pour tous les identifiants MySQL ou PostgreSQL accessibles depuis WHM ou l'interface utilisateur cPanel, auditer authorized_keys dans chaque répertoire personnel cPanel, auditer les tâches cron pour chaque utilisateur, auditer les installations WordPress hébergées pour des comptes admin inconnus et des fichiers core ou de thème modifiés, et examiner le gestionnaire de revendeur WHM et le gestionnaire de comptes pour des comptes que vous n'avez pas créés.

Cela représente une quantité significative de travail et c'est le coût réaliste d'une fenêtre zero-day de 60 jours dans une infrastructure critique. Le Centre canadien pour la cybersécurité a publié une alerte sur ce CVE sous la référence AL26-008 avec des conseils similaires. Si vous avez besoin d'aide pour exécuter l'audit, le service de gestion de Gotekky inclut le travail de réponse aux incidents pour les environnements cPanel.

Le schéma que cela représente

CVE-2026-41940 est le genre de vulnérabilité que l'industrie de l'hébergement traitera pendant des mois. La fenêtre zero-day de 60 jours est inhabituellement longue pour un contournement d'authentification critique et représente soit un échec de coordination entre chercheur et fournisseur, soit une exploitation active qui a devancé la divulgation. Quoi qu'il en soit, la leçon opérationnelle est que la confiance à périmètre unique dans tout plan de contrôle exposé à internet n'est plus adéquate. La défense en profondeur (ports d'administration derrière un pare-feu, plages d'IP restreintes pour l'accès WHM, surveillance des fichiers de session, application rapide des correctifs avec déploiement vérifié) est maintenant la norme minimale pour l'infrastructure cPanel, pas une étape de durcissement optionnelle. Nous déployons une surveillance supplémentaire sur les serveurs gérés à la suite de cet incident et publierons davantage sur ce travail dans un guide futur.