Le contournement de l'authentification cPanel révèle le risque croissant d'attaques centrées sur l'identité

Pourquoi un seul CVE met en évidence comment les pirates exploitent les erreurs de configuration, les faiblesses d'identité et l'automatisation pour obtenir un accès persistant

Ce qu’il faut retenir

• Les contournements d’authentification restent un point d’entrée à fort impact. Même les vulnérabilités de base présentes dans des panneaux de contrôle largement utilisés, tels que cPanel, peuvent permettre le piratage de comptes, une augmentation des privilèges et des attaques de suivi en cas d’exposition à Internet.
• Les failles d’identité amplifient les risques liés à l’infrastructure. Les mauvaises configurations, les contrôles d’accès faibles et les correctifs incomplets transforment l’identité en plan de contrôle que les pirates exploitent, souvent plus rapidement que ne le prévoient les défenseurs.
• Les pirates enchaînent de plus en plus les vulnérabilités grâce à l'automatisation. De l'abus d'identifiants aux outils alimentés par l'automatisation et l'IA, les campagnes modernes se concentrent sur la vitesse, l'échelle et la persistance plutôt que sur des exploits inédits.

Si vous avez déjà géré un serveur Web Linux, ou si vous avez fait appel à un hébergeur pour le faire à votre place, il y a de fortes chances que vous ayez croisé cPanel. Il se tient discrètement derrière une énorme part du Web, gérant fichiers, bases de données, e-mails, sauvegardes et accès utilisateur. C’est précisément la raison pour laquelle cette dernière vulnérabilité mérite plus qu’un simple avis de correctif.

Répertoriée sous la référence CVE‑2026‑41940, cette faille est un contournement d’authentification dans cPanel et WebHost Manager (WHM) qui peut permettre à des pirates distants non authentifiés d’obtenir un accès administratif par le biais du flux de connexion. Les rapports publics et les conseils des fournisseurs indiquent que le problème affecte les versions prises en charge après la version 11.40. Il a été corrigé le 28 avril 2026.

D'un point de vue risque, c'est proche d'un scénario catastrophe : un plan de contrôle privilégié et exposé à Internet avec un accès direct aux identités, configurations et données — et une faille qui contourne complètement les contrôles d'identité.

Ce qui rend cet incident particulièrement grave, c’est le moment où il s’est produit. Des informations publiques indiquent que la faille a été exploitée dans la nature avant d’être révélée, certaines tentatives ayant été observées fin février. Il est également juste de dire que la fenêtre de correctifs sera inégale selon les environnements d’hébergement, en particulier lorsque les mises à jour sont bloquées, retardées ou compliquées sur le plan opérationnel.

Campagnes de ransomware opportunistes

Deux exemples concrets permettent d’illustrer rapidement ce point. La première est la campagne de ransomware « Sorry ».

Une fois révélée au public, l’exploitation semble avoir rapidement pris une ampleur industrielle. Des articles ont fait état d’une campagne de grande ampleur exploitant la faille pour compromettre des serveurs et y déployer une souche de ransomware Linux connue sous le nom de « Sorry », chiffrant des fichiers et laissant des notes de rançon sur les systèmes compromis.

Les rapports basés sur les télémétries de Shadowserver suggèrent que plus de 40 000 adresses IP ont probablement été compromises ou impliquées dans des activités d’exploitation au cours de la vague d’attaques. Dans les environnements d’hébergement partagé, même cet ordre de grandeur approximatif indique un problème de risque en cascade : une couche de gestion compromise peut exposer un grand nombre d’identités, d’applications et de locataires en aval en une seule action.

Il ne s’agissait pas d’une attaque de précision. L’opération était automatisée, reproductible et ne nécessitait que peu d’efforts. C’est exactement ce à quoi l’on peut s’attendre lorsque des pirates trouvent un moyen de contourner les contrôles d’identité à grande échelle. Des attaques comme celle-ci deviennent partie intégrante du rayonnement de fond d’Internet. Les détails des exploits publics et les délais de correction créent généralement une longue traîne d’abus opportunistes successifs. 

Les attaques ciblées

Notre deuxième exemple concret est une exploitation ciblée contre les infrastructures gouvernementales et des MSP.

Parallèlement à l’activité des ransomwares, des rapports distincts décrivent une exploitation plus ciblée contre les gouvernements, l’armée, les fournisseurs de services gérés (MSP) et les infrastructures d’hébergement en Asie du Sud-Est et dans plusieurs autres pays. Dans ces cas, le contournement d’authentification cPanel a été rapporté comme un vecteur d’accès initial permettant une activité d’intrusion plus large.

Le point clé à retenir n’est pas l’attribution. Il s’agit d’une faiblesse de contournement d’identité unique qui a permis à la fois un déploiement de ransomware large et indiscriminé et une activité d’intrusion plus ciblée. C’est à cela que ressemble une exposition à fort impact en pratique.

Ce n’est pas seulement un problème de cPanel

Il est tentant de considérer les incidents de ce type comme des défaillances isolées de la plateforme. J’ai constaté les mêmes réflexions à la suite de la violation de Vercel, y compris l’affirmation familière selon laquelle l’incident était particulièrement grave parce qu’un grand nombre d’applications conçues par l’IA y atterrissaient par défaut. Mais l’enseignement tiré est plus large : les intégrations Open Authorization (OAuth) tierces peuvent discrètement devenir des ponts vers les systèmes centraux, et de nombreuses organisations en ont bien plus qu’elles ne le réalisent.

Presque toutes les entreprises ont connu une version de la même histoire : un accès accordé rapidement sous la pression du temps, des autorisations laissées en suspens, un nettoyage différé, et un chemin d’identité de faible importance se transformant discrètement en un chemin à fort impact plus tard. Par exemple : Timmy avait besoin d’un accès urgent au CRM et on lui a accordé des droits trop larges sur plusieurs systèmes pour qu’il soit rapidement opérationnel. L’administrateur a noté mentalement qu’il devait corriger les autorisations la semaine suivante, mais il ne l’a jamais fait. Le compte de Timmy détient désormais les clés du royaume, et il a la fâcheuse habitude de cliquer sur des choses qui semblent trop belles pour être vraies.

Il ne s’agit pas simplement d’un problème lié à Vercel, à cPanel ou à [insérez la plateforme ici]. C’est un problème de visibilité. C’est un problème d’hygiène de l’identité. Et il est partout.

Les LLM peuvent réduire la fenêtre d’exploitation industrielle

Le rôle croissant des grands modèles de langage dans le développement précoce des exploits est un accélérateur gênant de ce type d’incidents. Je dirais qu’il s’agit d’une compression plutôt que d’une révolution : les grands modèles de langage (LLM) peuvent réduire le temps et l’expertise nécessaires pour énumérer les voies d’attaque, élaborer une logique de preuve de concept et affiner les charges utiles, même s’ils ne remplacent pas les compétences pratiques des opérateurs.

Bien que je n’aie pas vu de preuves publiques solides liant cette dynamique spécifiquement à la faille de cPanel, les recherches de Marcus Hutchins sur Lazarus et les flux de travail des pirates assistés par l’IA offrent un exemple utile de la façon dont l’IA générative est déjà intégrée dans une véritable stratégie offensive. C’est également une excellente lecture pour le Read-Only Friday !

Le modèle de sécurité partagée est peut-être en train de s'effilocher discrètement

Des incidents comme ceux de cPanel et de Vercel mettent en évidence une tension plus profonde dans le modèle de sécurité partagée qui sous-tend les plateformes gérées. Sur le papier, la répartition des responsabilités est claire : les fournisseurs sécurisent la plateforme et les clients sécurisent ce qu’ils construisent dessus. En pratique, la prolifération des identités, la confiance héritée et les dépendances opaques brouillent ces frontières beaucoup plus rapidement que la plupart des organisations n’y sont préparées.

Lorsque quelque chose ne va pas, les équipes s’efforcent de répondre à des questions élémentaires mais cruciales :

• Quelles identités ont eu accès ?
• Quels sont les systèmes qui ont hérité d’une confiance implicite ?
• Quelles données ont été exposées ?
• Quelle distance un pirate peut-il raisonnablement parcourir ?

Il ne s’agit pas seulement de détails opérationnels, mais aussi de questions relatives aux risques. Et trop souvent, les plateformes gérées empêchent de répondre à ces questions en toute confiance, en particulier dans les environnements d’hébergement partagés et de petite taille où la visibilité, la journalisation et le contrôle peuvent manquer de régularité. Si l’on ajoute à cela la souveraineté des données et la pression réglementaire, on comprend mieux pourquoi certaines organisations commencent à se demander si la commodité l’emporte encore sur le contrôle.

Ce que les défenseurs devraient réexaminer dès maintenant : risque, identité et visibilité

Des incidents comme cPanel ne devraient pas être considérés comme des exercices isolés de correction. Il s’agit de signaux indiquant que le risque - en particulier le risque lié à l’identité - s’accumule plus rapidement et à plus d’endroits que de nombreuses équipes ne l’imaginent.

1. Il faut considérer les vulnérabilités comme des indicateurs de risque, et non comme de simples événements techniques. Demandez-vous ce qu'une faille expose en termes d'accès privilégié, de confiance héritée et de rayon d'impact en aval — en particulier dans les environnements partagés ou gérés.
2. Faites de l’identité une dimension de risque de premier ordre. Les jetons à longue durée de vie, les comptes de service, les clés API, les autorisations OAuth et les intégrations « set-and-forget » constituent désormais certaines des voies d’attaque les plus impactantes des environnements modernes. Si vous ne les voyez pas clairement, vous ne pouvez pas évaluer leur risque avec précision.
3. Exigez une visibilité sur les connexions, et pas seulement sur les actifs. Le risque réside dans la façon dont les systèmes, les identités et les permissions interagissent au fil du temps. Les défenseurs ont besoin d’une vision claire des zones où les risques augmentent, de la tendance de l’exposition et des angles morts avant que ces écarts ne se transforment en incidents.
4. Privilégiez la clarté des risques à la commodité. Les plateformes gérées privilégient la vitesse, mais les équipes de sécurité doivent privilégier la compréhension. Les organisations qui y parviennent ne se contentent pas de réagir plus rapidement : elles prennent de meilleures décisions, plus défendables, sur les risques acceptables et ceux qui ne le sont pas.

Retour à la question des résultats

C’est là qu’une approche axée sur les risques est essentielle. Les équipes n’ont pas besoin de plus d’alertes, elles ont besoin d’une vue unifiée et intelligible des risques liés à l’identité, aux e-mails, au réseau, aux applications, aux données et à l’IA. L’objectif est de normaliser la gravité, de mettre en évidence ce qui compte le plus et de traduire l’exposition technique en impact commercial et en tendances exploitables par les dirigeants.

Mise à jour : et parce que nous sommes en 2026, ce n’est pas tout

Alors que ce billet était en cours de finalisation, trois vulnérabilités supplémentaires liées à cPanel et WHM ont été révélées et corrigées, quelques jours seulement après que le premier contournement d’authentification ait été exploité à grande échelle. Les problèmes nouvellement traités incluent une lecture arbitraire de fichiers, une exécution arbitraire de code Perl et une faille d’escalade de privilèges — deux d’entre eux étant classés comme ayant une gravité élevée. Il est difficile de ne pas remarquer le moment choisi : un deuxième communiqué de sécurité d’urgence a été publié un vendredi, moins de deux semaines après le précédent. Comme l’explique l’article en lien, les opérateurs chevronnés reconnaîtront le schéma. Les incidents majeurs déclenchent des audits plus approfondis, et ces audits ont tendance à faire ressortir des conclusions plus gênantes - rarement à un moment opportun.

Aucune de ces nouvelles vulnérabilités n’a été confirmée publiquement comme exploitée dans la nature au moment de la rédaction. Pourtant, dans ce contexte, elles renforcent la conclusion plus large de cet article : lorsqu’un plan de contrôle hautement privilégié tombe en panne, le risque ne s’arrête rarement à une seule CVE. Les chemins de code adjacents deviennent intéressants très rapidement et les surfaces d’attaque ont tendance à se révéler par clusters plutôt que de manière isolée. La leçon à tirer n’est pas la panique, mais la gestion des attentes. Voici à quoi ressemble souvent la réalité post-incident dans de grandes plateformes profondément intégrées.

Certaines semaines nous rappellent que les expressions « bon week-end » et « mise à jour de sécurité urgente » ne sont pas incompatibles.