Noqta
écrits/blog/2026/05
● Blog16 mai 2026·6 min

cPanel CVE-2026-41940 : 44 000 serveurs compromis

CVE-2026-41940 : bypass d'authentification cPanel exploité depuis février 2026, 44 000 IP compromises. Le patch ne suffit pas, voici l'audit.

Anis Marrouchi
·EN · FR · AR

Le 30 avril 2026, la presse spécialisée a confirmé ce que les équipes incident response soupçonnaient : la vulnérabilité CVE-2026-41940 dans cPanel/WHM est exploitée comme zero-day depuis le 23 février 2026. Au moment de l'annonce publique, Censys avait déjà recensé environ 44 000 adresses IP compromises, avec dépôt d'artéfacts de ransomware suivant le motif .sorry sur une partie des serveurs touchés.

cPanel/WHM gère environ 70 millions de domaines dans le monde. En Tunisie, ce panel domine le marché de l'hébergement mutualisé : la quasi-totalité des hébergeurs locaux (et des revendeurs WHM) le déploient comme couche d'administration par défaut. Si votre site WordPress, votre boutique PrestaShop ou votre mailing transactionnel passent par un hébergement mutualisé tunisien, la question n'est pas « suis-je concerné » — c'est « mon compte a-t-il été touché entre le 23 février et l'application du correctif ».

Et il y a un piège : patcher ne ferme pas les portes dérobées déjà installées.

La CVE en clair : ce que la faille permet

CVE-2026-41940 est un bypass d'authentification dans cPanel/WHM. Un attaquant non authentifié peut, via une séquence de requêtes HTTP malformées vers les ports de gestion (2082, 2083, 2086, 2087), obtenir une session privilégiée sans connaître le moindre mot de passe.

Une fois la session obtenue, l'attaquant peut :

  • Lire et modifier les comptes hébergés sur la machine (tous, pas seulement un).
  • Déposer des web shells dans n'importe quel public_html.
  • Créer des comptes utilisateurs cPanel avec accès SSH, FTP, base de données.
  • Manipuler les enregistrements DNS gérés depuis le WHM.
  • Réinitialiser les mots de passe des comptes mail, FTP, bases MySQL.
  • Planifier des tâches cron sous n'importe quel utilisateur.

Sur un serveur mutualisé tunisien typique qui héberge 200 à 800 comptes, une seule exploitation expose l'intégralité des sites du serveur, pas seulement le compte ciblé. C'est la mécanique classique de la contamination croisée en hébergement partagé.

Côté correctif, cPanel a publié les versions corrigées dans la chaîne 11.126.x via le canal habituel /scripts/upcp. Les hébergeurs qui appliquent upcp automatiquement ont reçu le correctif courant avril 2026. Ceux qui ont désactivé les mises à jour automatiques — pratique courante chez certains revendeurs WHM — peuvent encore tourner sur une version vulnérable.

Suis-je concerné ? Vérifier en 3 minutes

Vous n'avez pas besoin d'accès root. Trois vérifications suffisent à cadrer le risque.

1. La version cPanel de votre serveur

Demandez par e-mail à votre hébergeur la sortie exacte de cette commande, exécutée sur le serveur qui héberge votre compte :

/usr/local/cpanel/cpanel -V

Si la réponse est antérieure à la 11.126.x publiée mi-avril 2026, votre serveur a été vulnérable au moins pendant la fenêtre d'exploitation. Demandez également la date exacte d'application du correctif. Toute période entre le 23 février 2026 et cette date est une fenêtre de compromission possible.

2. La question que votre hébergeur doit accepter de répondre par écrit

Posez ces cinq questions par e-mail (gardez la trace écrite, elle servira en cas d'incident) :

  1. Sur quel(s) serveur(s) précisément mon compte est-il hébergé ?
  2. Quelle version de cPanel/WHM tournait sur ce serveur entre le 23 février et le 30 avril 2026 ?
  3. À quelle date exacte le correctif CVE-2026-41940 a-t-il été appliqué ?
  4. Une analyse post-incident (recherche d'IoC) a-t-elle été conduite sur le serveur ?
  5. Avez-vous identifié, sur votre infrastructure, des comptes clients touchés ?

L'absence de réponse claire à l'une de ces questions est, en soi, un signal d'alerte. La loi tunisienne 2004-63 ne contient pas d'obligation générale de notification de violation, mais cela ne dispense pas votre hébergeur de transparence contractuelle.

3. Vérifier l'expiration de session de votre cPanel

Connectez-vous à votre cPanel. Si vous voyez dans l'historique d'accès (« Last Login from » en haut de la page d'accueil) une IP que vous ne reconnaissez pas, ou une connexion à une heure improbable depuis février 2026, traitez-le comme une compromission jusqu'à preuve du contraire.

Indicateurs de compromission (IoC) à chercher dans votre compte

Ces signes ne nécessitent pas d'accès root : ils sont visibles depuis l'interface cPanel ou un simple FTP/SSH utilisateur.

  • Tâches cron que vous n'avez jamais créées. Dans cPanel → « Cron Jobs ». Les attaquants déposent typiquement un cron toutes les 5 ou 15 minutes lançant un wget ou curl vers une URL externe.
  • Pics anormaux dans la file mail. Dans cPanel → « Email Deliverability » ou « Mail Queue ». Si votre file contient des centaines ou milliers de messages sortants vers des destinataires inconnus, votre compte sert à du spam abuse — motif fréquent de monétisation post-compromission.
  • Processus inconnus dans le panel. Si votre offre expose l'accès aux processus (rarement le cas en mutualisé), cherchez des binaires aux noms aléatoires (./xmrig, ./kdevtmpfsi, ./kinsing) — signatures classiques de cryptominers.
  • .htaccess modifié récemment. Téléchargez tous les .htaccess de votre site et comparez-les à votre dernière sauvegarde. Les attaquants y ajoutent souvent des règles de redirection conditionnelle (SEO spam, redirection vers du pharma/casino selon le user-agent).
  • Fichiers PHP dans des répertoires anormaux. wp-content/uploads/, pub/media/, images/, cache/ ne doivent jamais contenir de fichier .php. Cherchez-en : 
    find ~/public_html -name "*.php" -path "*/uploads/*" -o -path "*/cache/*"
  • Forwarders mail inconnus. Dans cPanel → « Forwarders ». Tout transfert vers une adresse externe que vous n'avez pas créée est suspect.
  • Comptes FTP ou SSH supplémentaires. Dans cPanel → « FTP Accounts » et « SSH Access ». Listez tous les comptes et identifiez chacun.
  • Clés SSH publiques inconnues dans ~/.ssh/authorized_keys. Si présentes, c'est une persistance à long terme.

Si un seul de ces indicateurs est positif, partez du principe que votre compte est compromis et passez au playbook de remédiation.

Le piège : patché mais toujours compromis

Le correctif cPanel ferme la porte d'entrée. Il ne nettoie pas la maison.

Si un attaquant a exploité CVE-2026-41940 sur votre serveur le 1er mars 2026 et que votre hébergeur a appliqué le patch le 15 avril, l'attaquant a eu 45 jours pour :

  • Déposer plusieurs web shells dans plusieurs comptes.
  • Créer des utilisateurs FTP/SSH de secours.
  • Ajouter ses clés SSH dans des comptes utilisateurs.
  • Modifier wp-config.php, configuration.php, app/etc/env.php pour exfiltrer des identifiants.
  • Planter des tâches cron de persistance.
  • Injecter des skimmers Magecart dans les templates de boutiques en ligne.

Toutes ces persistances survivent au patch. Le correctif empêche un nouvel attaquant d'entrer par la même faille — l'ancien a déjà ses propres clés. C'est le scénario qui se rejoue à chaque grande CVE d'infrastructure : Log4Shell en 2021, ProxyShell en 2022, MOVEit en 2023, cPanel en 2026.

Playbook de remédiation post-incident

Si votre hébergeur a tourné en version vulnérable durant la fenêtre 23 février – avril 2026, appliquez les quatre étapes ci-dessous dans l'ordre, même si vous ne voyez aucun IoC.

Étape 1 — Audit intégrité du compte

L'objectif est de cartographier toutes les modifications survenues depuis février.

  • Liste des fichiers PHP modifiés depuis le 1er février 2026 : 
    find ~/public_html -name "*.php" -newermt "2026-02-01" -ls > audit-php.txt
  • Diff entre les wp-config.php / configuration.php / app/etc/env.php et la dernière sauvegarde de référence pré-incident.
  • Inventaire des cron jobs, forwarders, comptes FTP, comptes mail, clés SSH via l'interface cPanel.
  • Logs d'accès des 90 derniers jours : téléchargez les access logs depuis cPanel → « Raw Access » et cherchez les requêtes vers /wp-admin/admin-ajax.php, /xmlrpc.php, ou les chemins d'upload de votre CMS, provenant d'IP que vous ne reconnaissez pas.

Étape 2 — Rotation totale des identifiants

Tout ce qui est stocké sur le serveur doit être considéré comme exposé. Tournez, dans cet ordre :

  1. Mot de passe cPanel (depuis l'interface).
  2. Tous les comptes FTP et SFTP.
  3. Tous les utilisateurs MySQL et leurs mots de passe (penser à mettre à jour les wp-config.php, etc.).
  4. Toutes les boîtes mail (mots de passe applicatifs y compris).
  5. Toutes les clés API stockées sur le serveur (Stripe, PayPal, Mailgun, SMTP, S3, etc.).
  6. Tous les comptes admin WordPress / PrestaShop / Magento.
  7. Toutes les clés SSH (révoquer puis re-déposer une nouvelle paire).
  8. Token API du compte cPanel s'il en existe un.

Ne réutilisez aucun mot de passe ancien. Utilisez un gestionnaire (1Password, Bitwarden) pour les nouveaux.

Étape 3 — Nettoyage des web shells

Recherchez les signatures classiques :

grep -rE "eval\(base64_decode|gzinflate\(base64_decode|str_rot13\(|assert\(\\\$_(POST|GET|REQUEST)" ~/public_html

Pour chaque résultat, vérifiez s'il s'agit d'un fichier que vous avez vous-même installé (rarement) ou d'un dépôt malveillant. Ne supprimez pas immédiatement sans avoir sauvegardé une copie hors-ligne — utile pour la forensique et pour identifier d'éventuelles autres compromissions.

Restaurez ensuite vos templates depuis une sauvegarde antérieure au 23 février 2026. Si votre sauvegarde la plus ancienne est postérieure à cette date, il faut considérer qu'elle peut contenir déjà du contenu malveillant.

Étape 4 — Reconstruction si l'intégrité reste douteuse

Quand l'audit révèle plusieurs IoC, ou que les sauvegardes pré-incident n'existent pas, la seule réponse propre est :

  1. Créer un compte cPanel vierge chez l'hébergeur (ou mieux, sur une autre infrastructure).
  2. Réinstaller le CMS à partir de l'archive officielle.
  3. Réimporter uniquement les données (base, fichiers média) après scan antivirus.
  4. Recréer manuellement les comptes utilisateurs.
  5. Couper l'ancien compte.

C'est lourd. C'est aussi la seule garantie de repartir sur une base saine quand un attaquant a eu plusieurs semaines pour s'installer.

Le vrai problème : le modèle « l'hébergeur gère la sécurité »

Cet incident expose une croyance répandue dans le tissu PME tunisien : « l'hébergeur s'occupe de la sécurité de mon site ». Ce n'est vrai qu'en partie.

L'hébergeur mutualisé est responsable de l'OS, du panel cPanel/WHM, du réseau, du pare-feu de base, des certificats SSL et de la disponibilité.

Il n'est généralement pas responsable du code de votre site (CMS, thèmes, modules), des mots de passe de vos comptes utilisateurs, de la sauvegarde applicative (sauf clause explicite), de la détection des web shells dans votre compte, ni de la notification quand un incident le touche.

Et c'est là que le bât blesse en Tunisie : il n'existe pas, dans la loi 2004-63 ni dans le décret 2022-54, d'obligation générale de notification de violation de données comparable au RGPD ou au PDPL saoudien. Un hébergeur peut savoir que 800 comptes clients ont été compromis et choisir de ne pas communiquer. Aucun régulateur ne l'y oblige.

Conséquence : la responsabilité de savoir repose entièrement sur vous. C'est à vous de demander la version cPanel, vérifier les IoC, tester vos backups, valider l'intégrité de votre code. Aucun hébergeur généraliste ne le fera spontanément pour 50 ou 200 dinars par mois.

C'est exactement le sujet qu'aborde notre article sur les contrats de maintenance de site web : la frontière entre « hébergement » et « maintenance applicative » est rarement explicite dans les contrats locaux, et c'est là que vit le risque.

L'alternative : un hébergement managé qu'on contrôle

L'approche que Noqta opère pour ses clients e-commerce et SaaS sort de la logique mutualisée :

  • VPS dédié (DigitalOcean, Hetzner, OVH) provisionné dans le compte du client — vous gardez la propriété de l'infrastructure.
  • Stack pinnée à jour (Ubuntu LTS, Nginx, PHP 8.3/8.4 ou Node 22 LTS, MySQL 8.4 LTS).
  • Monitoring 24/7 : disponibilité, charge, expiration certificats, intégrité fichiers, file mail.
  • Sauvegardes 3-2-1 : trois copies, deux supports, une copie hors site. Restauration testée tous les trimestres.
  • Audit trimestriel : version stack vs EOL, composer audit / npm audit, revue des accès.
  • Notification d'incident sous 24 h, engagée contractuellement.

Quand la prochaine CVE tombera — et elle tombera — vous saurez sous 24 h si vous êtes concerné, et le plan de remédiation sera déjà documenté.

Tarification indicative : forfait mensuel hébergement managé + forfait audit trimestriel. Devis sur cadrage.

CTA : audit post-incident cPanel — forfait 4 heures

Si vous opérez un site sur hébergement mutualisé tunisien et que cet article vous laisse un doute, nous proposons un audit post-incident cPanel en forfait 4 heures :

  • Analyse des access logs des 90 derniers jours.
  • Scan web shells, signatures connues, fichiers PHP suspects.
  • Diff intégrité des fichiers de configuration sensibles.
  • Inventaire : cron, forwarders, comptes FTP/SSH, clés.
  • Rapport priorisé et plan de rotation des identifiants.
  • Recommandation : nettoyage in-situ ou reconstruction.

Quatre heures, livrable écrit, action concrète à la fin.

Demander l'audit post-incident cPanel

Sources publiques : TechCrunch (« Hackers are actively exploiting a bug in cPanel used by millions of websites », 30 avril 2026), The Hacker News (« Critical cPanel authentication bypass »), SecurityWeek (« Critical cPanel/WHM vulnerability exploited as zero-day for months »), Censys (~44 000 IP compromises, dépôt d'artéfacts .sorry). Cadre légal : loi tunisienne 2004-63 du 27 juillet 2004 sur la protection des données personnelles, décret 2022-54.