La sécurité d'un hébergement web se joue dans les heures qui suivent la divulgation d'une faille. Ce n'est pas la liste des fonctionnalités qui en décide. Cet article explique comment InMotion Hosting a géré la faille CVE-2026-41940, une faille « zero-day » critique de type « cPanel ». Il précise quelles protections fonctionnent automatiquement sans que tu aies rien à faire, ce qui reste de ta responsabilité selon chaque type de forfait, et les questions à poser à n'importe quel hébergeur avant que la prochaine faille critique ne se présente.
L'hébergement web sécurisé, ça dépend surtout de la rapidité avec laquelle ton hébergeur peut corriger la faille dès qu'une faille critique est rendue publique. En pratique, ça repose sur trois éléments. L’hébergeur bloque le service vulnérable à la périphérie du réseau en quelques heures. Il applique les correctifs sur tous les serveurs sans attendre que les clients agissent. Et il donne des instructions claires au petit groupe de personnes qui ont besoin d’une aide pratique. Lorsque cPanel a révélé la faille CVE-2026-41940 le 28 avril 2026, InMotion Hosting a respecté ces trois conditions. Sur les 144 870 clients potentiellement exposés, 99 % sont restés protégés sans aucune interruption de service.
Pourquoi la « fenêtre de mise à jour » est-elle le chiffre le plus important en matière de sécurité de l'hébergement web ?
Les pirates ont changé leur mode d'attaque préféré. Le rapport 2026 de Verizon sur les enquêtes relatives aux fuites de données a révélé que l'exploitation de vulnérabilités combinée à l'utilisation d'identifiants volés était désormais le principal vecteur d'accès initial, une première dans l'histoire du rapport, représentant désormais 31 % des cas d'accès initial. Du côté des défenseurs, c'est l'inverse qui s'est produit. Le délai médian pour appliquer toutes les correctives est passé à 43 jours, contre 32 l'année précédente.
Quarante-trois jours, ça poserait déjà un problème même si les pirates attendaient que des correctifs soient disponibles. Mais ce n’est pas le cas. Le rapport « M-Trends 2026 » de Mandiant estime que le délai moyen avant l’exploitation d’une faille est de moins sept jours, ce qui veut dire que les attaques commencent systématiquement avant même qu’un correctif ne soit publié.
WordPress Les sites sont soumis à des délais encore plus serrés. Le rapport « State of WordPress Security in 2026 » de Patchstack estime à cinq heures la durée médiane pondérée avant la première exploitation. Ce même rapport révèle que 46 % des vulnérabilités WordPress n’avaient pas de correctif disponible au moment de leur divulgation.
Imagine un commerçant qui met à jour ses plugins tous les vendredis matins. Lui, ça se passe toutes les semaines, alors que les pirates, ça se passe toutes les heures. Certaines couches sont complètement hors de sa portée : le panneau de contrôle, le noyau Linux et le réseau. Pour celles-là, la seule fenêtre de mise à jour qui compte, c'est celle de l'hébergeur.
À quoi ressemblait vraiment la réponse à une faille « zero-day » pour le CVE-2026-41940 d'cPanel ?
CVE-2026-41940 est une faille permettant de contourner l'authentification préalable dans cPanel et WHM, avec un score CVSS de 9,8. Des chercheurs de watchTowr Labs ont découvert qu'elle exploitait en chaîne trois failles distinctes dans la façon dont cPanel gère les connexions et les sessions. Un pirate capable d’accéder à un serveur vulnérable n’avait besoin ni d’identifiant, ni de mot de passe, ni de code 2FA pour obtenir un accès root. D’après les données de Shodan, environ 1,5 million d’instances d’ cPanel exposées sur Internet étaient menacées.
Cette faille était déjà exploitée avant même que la plupart des gens ne sachent qu'elle existait. Des chercheurs ont signalé des preuves d'exploitation dès la fin février 2026, soit environ deux mois avant que l'cPanel ne publie un correctif. La CISA a ensuite fixé au 3 mai la date limite pour que les agences fédérales corrigent le problème.
| Date | Étape importante |
|---|---|
| Fin février 2026 | Les chercheurs ont ensuite retracé la première preuve d'exploitation jusqu'à cette fenêtre |
| 28 avril | cPanel publie le correctif ; InMotion ferme les ports concernés au niveau de la périphérie du réseau dans les trois régions de centres de données en quelques heures et lance l'application automatisée des correctifs |
| 30 avril | La CISA ajoute CVE-2026-41940 à son catalogue des vulnérabilités connues faisant l'objet d'exploits |
| 1er mai | InMotion publie son suivi technique avec les étapes de vérification destinées aux administrateurs de serveurs |
| 13 mai | cPanel publie une deuxième mise à jour couvrant cinq CVE supplémentaires ; InMotion l'applique aux environnements gérés le jour même |
Comment ces deux voies parallèles ont-elles permis de maintenir les sites en ligne ?
La première étape a permis de réduire la surface d'attaque. L'équipe d'exploitation réseau d'InMotion a fermé les ports de gestion d'cPanel, de WHM, de Webmail et de WebDisk (2082, 2083, 2086, 2087, 2095, 2096, 2077 et 2078) au niveau de la périphérie du réseau dans les centres de données de la côte Est des États-Unis, de la côte Ouest des États-Unis et d'Europe. Les sites web, les applications, les bases de données et les e-mails fonctionnent sur des ports standard, ils ont donc continué à fonctionner. Le panneau de gestion des comptes (AMP) est également resté accessible.
La deuxième approche a permis de corriger la faille sous-jacente. Les ingénieurs ont peaufiné les scripts automatisés pour déployer la mise à jour officielle « cPanel » sur tous les serveurs éligibles. Ils n’ont rouvert l’accès aux ports sur chaque serveur qu’après avoir vérifié que la version corrigée était bien installée. Certains serveurs n’ont pas pu recevoir la mise à jour à cause d’un verrouillage de version ou d’une version « cPanel » en fin de vie. Ces serveurs sont restés bloqués, et l’équipe a contacté directement leurs propriétaires. Certains de ces clients ont été transférés vers du matériel neuf et ont reçu les nouvelles coordonnées de leurs serveurs ainsi que des listes de contrôle pour la migration.
« Pour la plupart de nos clients en gestion, tout s’est déroulé sans qu’ils aient à lever le petit doigt. Pour la petite partie dont les environnements nécessitaient une intervention directe, notre équipe a pris contact de manière proactive pour leur proposer des étapes claires à suivre et est restée à leurs côtés jusqu’à ce que tout soit résolu. C’est exactement ce à quoi devrait ressembler une relation de gestion d’hébergement. » John Joseph, directeur de la réussite client, InMotion Hosting
cPanel , c'est toujours un panneau de contrôle fiable ?
Oui. Tout logiciel installé sur des centaines de milliers de serveurs connectés à Internet va forcément attirer l’attention des chercheurs, et certaines de ces recherches vont mettre au jour des failles critiques. Le chiffre de 1,5 million reflète l’ampleur de la propagation d’ cPanel. Ça ne veut pas dire pour autant qu’ cPanel soit particulièrement vulnérable. cPanel a publié un correctif ainsi qu’un script permettant aux administrateurs de détecter les signes d’une intrusion. Ta vulnérabilité dépend de la rapidité avec laquelle ton hébergeur réagit à ce genre de mises à jour.
En quoi un réseau privé propre permet-il d'accélérer la protection contre les failles « zero-day » ?
La plupart des hébergeurs protègent un service vulnérable en ajoutant des règles de pare-feu sur chaque serveur. Ça marche, mais c'est lent. Le temps nécessaire pour obtenir une couverture complète augmente avec le nombre de serveurs, et chaque serveur doit être joignable et en bon état de fonctionnement pour accepter la règle. Comme InMotion tourne sur son propre matériel et un réseau privé, il peut appliquer le blocage en une seule fois à la périphérie de chaque région. Le trafic malveillant n'atteint donc jamais le serveur.
| Facteur | Bloc de périphérie de réseau | Blocage serveur par serveur |
|---|---|---|
| Dans quels cas cette règle s'applique-t-elle ? | Avant que le trafic n'atteigne un serveur | Sur le pare-feu de chaque serveur |
| Qui peut l'utiliser ? | L'opérateur qui gère le réseau | Un administrateur sur chaque serveur |
| Délai avant couverture complète | Un changement par région | Évolue en fonction du nombre de serveurs |
| Les serveurs épinglés, obsolètes ou négligés | Couverture automatique | On peut facilement passer à côté |
| Impact sur le trafic du site web | Aucun lorsque seuls les ports de gestion se ferment | Aucun, si c'est bien configuré |
« Comme on possède et gère notre propre infrastructure réseau mondiale, notre équipe chargée de l'exploitation du réseau a bloqué l'accès externe aux ports vulnérables situés à la périphérie de notre réseau quelques heures seulement après la divulgation de la faille. » Erik Soroka, directeur des opérations informatiques et des centres de données, InMotion Hosting
Tu ne verras jamais ça sur une page de tarifs. Et pourtant, c'est ça qui détermine si l'exposition dure quelques heures ou plusieurs jours.
Quelles mesures de sécurité s'exécutent automatiquement sur un hébergement géré ?
La réponse « cPanel » n'était pas un cas isolé. Plusieurs autres mesures de protection sont désormais en place sur l'ensemble du parc d'InMotion, sans que les clients aient besoin de configurer quoi que ce soit.
Mises à jour du panneau de contrôle le jour même. Le 13 mai 2026, cPanel a publié des correctifs pour cinq autres failles de sécurité classées jusqu'au niveau « Élevé ». InMotion a appliqué cette mise à jour sur tous les environnements gérés (hébergement mutualisé, WordPress, revendeurs, VPS et serveurs dédiés) le jour même de sa publication, et les clients n'ont rien eu à faire.
Mesure de protection au niveau du noyau avant l'intégration des correctifs en amont. La faille « Dirty Frag » a été révélée le 7 mai 2026. Elle exploite en chaîne deux failles du noyau Linux (CVE-2026-43284 et CVE-2026-43500), permettant à un utilisateur local sans privilèges d'obtenir les droits root sur la plupart des principales distributions. C'est un problème sur les serveurs d'hébergement, car un compte de site compromis peut devenir un « utilisateur local ». InMotion a empêché le chargement des modules du noyau concernés sur l'ensemble de son parc de serveurs dédiés. Les clients VPS ont été protégés automatiquement au niveau des nœuds sous-jacents.
Protection des applications en temps réel. En août 2026, InMotion a déployé Monarx ThreatShield sur l’ensemble de son parc de serveurs. ThreatShield s’exécute au sein du moteur PHP et surveille ce que fait réellement le code au fur et à mesure de son exécution. Cette couche de protection est essentielle, car les tests de Patchstack ont révélé que les défenses traditionnelles, telles que les WAF et ModSecurity, ne bloquaient que 12 % des attaques ciblant des vulnérabilités connues d’ WordPress .
Détection et suppression des logiciels malveillants. La solution de protection contre les logiciels malveillants Monarx, avec atténuation automatisée, est incluse dans l'offre Premier Care pour les serveurs VPS et dédiés. Elle est également disponible en option.
Quelles tâches de sécurité restes-tu en charge selon ton forfait d'hébergement ?
En matière de sécurité de l'hébergement géré, les responsabilités sont toujours partagées entre toi et ton hébergeur. La répartition exacte dépend de ta formule.
| Type de forfait | Mises à jour du panneau de configuration et du système d'exploitation | Ce que tu possèdes |
|---|---|---|
| Partagé, WordPress, Revendeur | Appliqué automatiquement par InMotion | WordPress noyau, plugins, thèmes, mots de passe, comptes utilisateurs et gestion des comptes clients pour les revendeurs |
| VPS géré, serveur dédié géré | Appliqué automatiquement par InMotion | La couche applicative, tes identifiants et les logiciels personnalisés que tu installes |
| VPS et serveurs dédiés en autogestion | InMotion te propose des conseils sur les correctifs et une assistance 24 h/24, 7 j/7 | Tout ce qui précède, plus la vérification des niveaux de correctifs, des mises à jour du noyau et du système d'exploitation, ainsi que des règles du pare-feu |
Pourquoi l'authentification à deux facteurs n'a-t-elle pas empêché cette attaque ?
Ça en surprend plus d'un parmi les propriétaires de sites. L'exploit CVE-2026-41940 marquait la session comme « vérifiée par l'authentification à deux facteurs » avant même qu'une invite d'authentification à deux facteurs n'apparaisse. Tant que les serveurs n'étaient pas corrigés, bloquer les ports était la seule défense fiable. Garde quand même l'authentification à deux facteurs activée. L'usurpation d'identifiants représente toujours une part importante des violations de sécurité, et l'authentification à deux facteurs (2FA) en empêche la plupart. Mais ne compte pas uniquement sur la 2FA pour te protéger d'une faille qui contourne complètement la procédure de connexion.
Quelles habitudes de sécurité sont toujours utiles ?
- Change tes identifiants dès qu'un avis est publié par le panneau de contrôle. Modifie tes mots de passe pour cPanel, WHM et tes bases de données. Considère que tous les identifiants stockés dans des fichiers situés dans ton répertoire racine sont compromis.
- Supprime les plugins que tu n'utilises pas. En 2025, les plugins représentaient 91 % des failles d'WordPress . Les plugins payants proposés sur les boutiques en ligne comportaient trois fois plus de failles connues et exploitées que les plugins gratuits.
- Active l'authentification à deux facteurs (2FA) pour les comptes cPanel, WordPress (compte administrateur) et les comptes de messagerie.
- Garde tes sauvegardes ailleurs que sur le serveur qu'elles protègent.
- Vérifie s'il y a des connexions ou des comptes que tu ne reconnais pas. Après la publication d'un avis, consulte l'historique des dernières connexions sur cPanelainsi que tes comptes FTP, tes comptes de messagerie et tes clés SSH.
Quels sont les points à vérifier pour les propriétaires de serveurs autogérés ?
Si tu gères ton propre VPS ou serveur dédié, vérifie la version d'cPanel via SSH :
/usr/local/cpanel/cpanel -VSi le résultat ne correspond pas à une version corrigée, force la mise à jour et redémarre le service « cPanel » :
/scripts/upcp --force
/scripts/restartsrv_cpsrvd --hardEnsuite, lance le script permettant de détecter les signes d'intrusion, disponible dans l'avis officiel publié parcPanel. Tu trouveras la liste de contrôle complète dans notre article technique de suivi.
Quelles questions devrais-tu poser à ton hébergeur au sujet de la sécurité ?
Pose ces questions avant de souscrire ou de renouveler ton contrat, pas quand un problème se présentera :
- Est-ce qu'on peut bloquer un service vulnérable à la périphérie du réseau dans tous les centres de données sans affecter le trafic du site web ? Une bonne réponse précise le mécanisme utilisé et le temps que ça prend.
- Quel est ton délai cible pour corriger les failles figurant sur la liste KEV de la CISA ? Les agences fédérales ont mis environ trois jours pour la faille CVE-2026-41940, alors que la médiane du DBIR est de 43 jours. Demande-toi à quoi ressemble le processus de ton hébergeur.
- Les clients en gestion doivent-ils faire quelque chose quand un correctif pour le panneau de contrôle ou le noyau est mis à disposition ? Avec un forfait en gestion, la réponse est généralement non.
- Qu'est-ce qui arrive aux serveurs qui ne peuvent pas installer le correctif ? Cherche un plan qui couvre les versions « épinglées » et les logiciels en fin de vie, pas seulement les cas faciles.
- Qui me contacte si mon environnement a besoin d'une intervention manuelle, et comment ? Une prise de contact proactive avec des étapes concrètes à suivre vaut mieux qu'une page d'état générique.
- Ton équipe d'assistance est-elle interne et disponible 24 h/24 et 7 j/7 en cas d'incident ? Les techniciens d'InMotion suivent plus de 280 heures de formation avant d'accéder au niveau 1, et leur ancienneté moyenne au sein du service d'assistance est supérieure à cinq ans.
- Qu'est-ce qui fonctionne au niveau de la couche applicative pour bloquer les failles avant qu'un correctif ne soit disponible ? La protection en temps réel couvre la période précédant la mise à disposition d'un correctif, pendant laquelle les correctifs seuls ne suffisent pas.
Est-ce qu'un VPS géré ou un hébergement dédié géré correspond le mieux à tes besoins en matière de sécurité ?
L'hébergement géré est particulièrement indiqué dans trois situations. Ton site génère des revenus à chaque heure où il est en ligne. Tu es une agence chargée de gérer les sites de tes clients. Ou bien personne dans ton équipe n'a le temps de suivre les avis de sécurité d'cPanel et les informations sur les vulnérabilités du noyau. Dans chacun de ces cas, la valeur ajoutée principale réside dans les correctifs qui s'installent automatiquement, sans que tu aies rien à faire.
L'hébergement VPS géré convient à la plupart des sites d'entreprises individuelles et aux boutiques WooCommerce en pleine croissance. Les serveurs dédiés gérés sont adaptés aux charges de travail à fort trafic, aux agences gérant des dizaines de sites clients et aux équipes qui ont besoin d'une isolation au niveau matériel. Si tu disposes d'un administrateur système compétent et que tu souhaites un contrôle root total, une formule autogérée est tout à fait adaptée, à condition que quelqu'un se charge de la liste des correctifs à appliquer.
Avec l'une ou l'autre de ces formules gérées, Premier Care inclut la protection contre les logiciels malveillants Monarx et un espace de sauvegarde dédié (300 Go sur les serveurs VPS, 500 Go sur les serveurs dédiés). Elle comprend également une assistance produit avancée prioritaire sur les serveurs VPS et une heure par mois de conseil InMotion Solutions sur les serveurs dédiés.
La prochaine faille CVE critique va bientôt sortir. Choisis un hébergeur qui a déjà prouvé qu'il pouvait corriger les vulnérabilités en quelques heures. Contacte notre équipe pour trouver la formule de gestion adaptée à ta charge de travail.