# Un rançongiciel qui a chiffré 40 sites d’un même serveur mutualisé WordPress > Un hébergeur dont l'isolation entre comptes était insuffisante a permis à un rançongiciel de se propager d'un site compromis aux 40 autres du même serveur. - Auteur : Clément Hadrot - Publié le : 2026-02-14 - Mis à jour le : 2026-02-14 - Catégorie : Sécurité - URL : https://wpmoderne.dev.wordpress-developpement.fr/securite/ransomware-40-sites-serveur-mutualise/ ## L’essentiel - Un seul site vulnérable a suffi de point d'entrée - L'absence d'isolation utilisateur a permis la propagation latérale - Les 39 autres clients n'avaient commis aucune erreur de leur côté L'incident concerne un hébergeur de taille moyenne, spécialisé dans l'hébergement mutualisé à bas coût pour petites entreprises, qui hébergeait sur un même serveur physique quarante sites WordPress appartenant à des clients totalement indépendants les uns des autres, sans aucun lien de gestion commun. Un matin, l'un de ces clients a découvert que son site affichait une page unique, en anglais, annonçant que l'intégralité de ses fichiers avait été chiffrée et exigeant le paiement d'une rançon en cryptomonnaie pour obtenir la clé de déchiffrement. En quelques heures, il est apparu que les trente-neuf autres sites du même serveur présentaient exactement le même symptôme. L'enquête menée en collaboration avec l'hébergeur a permis de reconstituer la chaîne complète de l'attaque, depuis le point d'entrée initial jusqu'à la propagation à l'ensemble du serveur, révélant une défaillance d'isolation qui n'avait rien à voir avec une négligence de sécurité de la part des trente-neuf sites finalement touchés sans faute de leur part. ## Le point d'entrée : un seul site, une extension obsolète Le point d'entrée initial a été identifié sur un seul des quarante sites : une extension de galerie photo, installée plusieurs années auparavant et jamais mise à jour depuis, présentait une vulnérabilité d'upload de fichier non filtré, permettant à un attaquant de déposer un fichier PHP exécutable dans le dossier `wp-content/uploads/galerie/`, un répertoire censé n'accueillir que des images, mais dépourvu de toute restriction empêchant l'exécution de scripts PHP. Une fois ce fichier déposé et exécuté, l'attaquant disposait d'un accès en ligne de commande limité aux permissions de l'utilisateur système sous lequel ce site s'exécutait. ## La propagation : une isolation entre comptes qui n'existait pas réellement > L'essentiel à retenir : Un seul site vulnérable a suffi de point d'entrée ; L'absence d'isolation utilisateur a permis la propagation latérale ; Les 39 autres clients n'avaient commis aucune erreur de leur côté Sur une infrastructure mutualisée correctement isolée, chaque site s'exécute sous un utilisateur système distinct (une pratique courante appelée *suPHP* ou *PHP-FPM* par pool utilisateur), avec des permissions de fichiers empêchant un utilisateur d'accéder aux fichiers d'un autre compte, même en cas de compromission complète de l'un d'eux. Sur ce serveur précis, l'audit post-incident a révélé que les quarante sites, bien que présentés comme des comptes d'hébergement distincts dans l'interface client, s'exécutaient en réalité sous un seul et même utilisateur système partagé, un choix de configuration hérité d'une ancienne génération de panneau de contrôle jamais migrée vers un modèle d'isolation plus strict. Cette absence d'isolation signifiait que le script PHP malveillant déposé sur le premier site disposait, dès son exécution, des permissions de lecture et d'écriture sur l'intégralité des répertoires des trente-neuf autres sites hébergés sur le même serveur, situés dans des dossiers frères du même arbre de fichiers, sans aucune barrière système entre eux : ``` ls -la /home/hebergement-mutualise/ drwxr-xr-x www-data www-data site-client-01 drwxr-xr-x www-data www-data site-client-02 drwxr-xr-x www-data www-data site-client-03 # ... les 40 sites, tous sous le même utilisateur système "www-data" ``` Le rançongiciel, une fois son premier accès obtenu, a simplement parcouru l'arborescence complète accessible depuis son propre contexte d'exécution, chiffrant récursivement tous les fichiers rencontrés, sans distinction entre le site initialement compromis et les trente-neuf autres, techniquement des cibles totalement passives de la propagation. ## Ce que les 39 autres clients n'auraient rien pu faire pour éviter Le point le plus important à souligner sur cet incident, du point de vue des clients concernés, est qu'aucune de leurs pratiques individuelles de sécurité n'aurait changé l'issue. Certains parmi les trente-neuf sites touchés appliquaient scrupuleusement les mises à jour automatiques, disposaient d'une authentification à deux facteurs sur leurs comptes administrateur, et n'avaient installé aucune extension obsolète. Rien de tout cela n'aurait empêché la propagation, parce que la faille exploitée n'appartenait à aucun de leurs sites : elle appartenait à l'infrastructure sous-jacente, un choix d'isolation que ces clients n'avaient ni les moyens de vérifier, ni la possibilité de corriger eux-mêmes. - La sécurité d'un site WordPress dépend d'une couche que son propriétaire ne maîtrise jamais directement : l'isolation offerte par son hébergeur. - Un audit de sécurité centré uniquement sur la configuration WordPress, aussi rigoureux soit-il, ne peut jamais couvrir ce risque, situé une couche en dessous. - La seule protection réelle contre ce scénario est le choix de l'hébergement lui-même, avant même la mise en ligne du site. ## Ce qui a permis la restauration Les sites qui ont pu être restaurés rapidement, sans céder à la demande de rançon, étaient ceux dont les sauvegardes étaient stockées sur une infrastructure distincte du serveur compromis, un principe de sauvegarde déjà abordé sur ce blog : une sauvegarde stockée sur le même serveur que celui qu'elle est censée protéger n'offre aucune garantie en cas de compromission du serveur dans son ensemble, puisqu'elle est chiffrée en même temps que tout le reste. Sur ce serveur précis, environ un tiers des sites disposait d'une sauvegarde externalisée récente, ce qui a permis une restauration en quelques heures. Les autres ont dû reconstruire depuis des sauvegardes plus anciennes, avec une perte de contenu correspondante, ou négocier avec l'hébergeur des solutions de récupération partielle. > Une sauvegarde qui vit sur le même serveur que le site qu'elle protège n'est pas une sauvegarde, c'est une copie qui subira le même sort au même moment. ## Les questions à poser à un hébergeur mutualisé avant de lui confier un site Cet incident a conduit l'agence impliquée dans la remédiation à formaliser une grille de questions à poser systématiquement à tout hébergeur mutualisé envisagé pour un nouveau client, avant toute mise en ligne : - Chaque compte d'hébergement s'exécute-t-il sous un utilisateur système distinct, avec des permissions de fichiers empêchant tout accès croisé entre comptes ? - L'hébergeur peut-il démontrer, et pas seulement affirmer, cette isolation, par exemple via une documentation technique ou un test contrôlé ? - Les sauvegardes proposées par l'hébergeur sont-elles stockées sur une infrastructure physiquement distincte du serveur de production ? ## Ce qu'il faut retenir Cet incident illustre un risque que la sécurité WordPress, centrée sur le code, les extensions et les configurations applicatives, aborde rarement : celui d'une isolation défaillante au niveau de l'infrastructure elle-même, invisible depuis l'intérieur de WordPress et pourtant capable de transformer la compromission d'un seul site négligé en catastrophe collective pour un serveur entier. Le choix d'un hébergeur garantissant une isolation stricte entre comptes n'est pas un détail commercial, c'est une décision de sécurité à part entière, qui mérite d'être vérifiée avec la même rigueur que le choix d'une extension ou d'un thème.