Guides

Sécurité WordPress Multisite : durcir tout un réseau

29 avril 2026 · Mise à jour 28 septembre 2026 · Patrick Schlesinger

La sécurité de WordPress Multisite ne cède pas aux mêmes endroits que celle d’un site isolé : une base de code commune, une base de données unique et une table d’utilisateurs globale font qu’un seul sous-site fragile peut ouvrir tout le réseau à un attaquant. Ce guide présente le modèle de menace du Multisite, une liste de contrôle de durcissement en 10 points et la raison pour laquelle un blocage à l’échelle du réseau comble la faille que laissent les outils de sécurité site par site.

Pourquoi sécuriser un réseau Multisite est différent de sécuriser un site unique

Un réseau WordPress Multisite ressemble à plusieurs sites, mais techniquement il s’agit d’une seule installation. Cinq propriétés définissent son modèle de menace :

• Une seule base de code. Chaque sous-site exécute le même cœur WordPress, les mêmes fichiers d’extensions et les mêmes fichiers de thème depuis un seul répertoire. Une faille dans une seule extension est exploitable sur chaque sous-site où cette extension est active.
• Une seule base de données. Les sous-sites ont leurs propres tables, mais aucune barrière de droits ne les sépare. Une injection SQL sur n’importe quel sous-site atteint toutes les tables de la base, y compris les tables du réseau.
• Des utilisateurs globaux. La table des utilisateurs est partagée par tout le réseau. Un compte créé sur un sous-site existe partout, et un mot de passe volé sur le sous-site le moins important fonctionne sur le plus important.
• Un seul processus PHP. Tous les sous-sites sont servis par le même serveur d’application avec les mêmes droits sur les fichiers. Exécuter du code sur un sous-site, c’est exécuter du code sur le réseau.
• Le rôle de super admin. Les super admins passent chaque contrôle de droits sur chaque sous-site. Un compte de super admin ne peut pas être compromis à moitié : si l’un d’eux se fait hameçonner, c’est tout le réseau qui tombe.

Conséquence pratique : un réseau Multisite est exactement aussi sûr que son sous-site le plus faible. Un site de test oublié avec une extension obsolète n’est pas un petit risque dans un coin ; c’est une porte vers tout le reste.

Quelles parties d’un réseau Multisite les attaquants sondent en premier

Entre mai et juillet 2026, le réseau communautaire ReportedIP a enregistré 1,69 million d’attaques contre des sites WordPress, et les points de connexion étaient la cible principale. Sur un Multisite, plusieurs de ces surfaces se multiplient avec le nombre de sous-sites :

Surface d’attaque	Pourquoi elle pèse plus sur un Multisite	Première contre-mesure
wp-signup.php	Une inscription ouverte permet à des robots de créer des comptes, voire des sous-sites entiers, sur tout le réseau.	Désactiver l’inscription dans les réglages du réseau ou la limiter aux comptes utilisateurs.
Pages de connexion	Chaque sous-site expose son propre formulaire de connexion, et tous vérifient les identifiants dans la même table d’utilisateurs.	Surveillance des connexions à l’échelle du réseau avec des compteurs partagés.
xmlrpc.php	Existe une fois par sous-site ; chaque copie accepte des tentatives d’authentification et des requêtes multicall amplifiées.	Le désactiver sur tout le réseau ou le limiter de façon centrale.
Énumération des utilisateurs via REST	Le point d’accès users peut révéler les identifiants globaux ; une seule requête cartographie les comptes de tout le réseau.	Bloquer l’énumération des utilisateurs pour les requêtes non authentifiées.
Sous-sites abandonnés	Les sous-sites laissés à l’abandon exécutent toujours toute la base de code, mais personne ne lit leurs journaux.	Supprimer ou archiver les sous-sites qui ne sont plus entretenus.
Domaines associés	Un domaine associé sans TLS valide expose les cookies d’authentification communs au réseau.	Servir chaque sous-site et chaque domaine associé avec un certificat valide.

Une liste de contrôle en 10 points pour durcir WordPress Multisite

Traitez les points dans l’ordre. Les points 1 à 3 éliminent les risques les plus lourds, les points 4 à 9 réduisent la surface d’attaque et le point 10 couvre la détection.

1. Fermer ou restreindre l’inscription. Le réglage Inscription de l’administration du réseau décide si des inconnus peuvent créer des comptes ou des sous-sites. Si l’inscription doit rester ouverte, ajoutez un blocage des adresses jetables et un honeypot dans le formulaire, afin que les inscriptions de robots échouent avant de créer de la charge.
2. Limiter la liste des super admins. Chaque compte de super admin hameçonné signifie la perte du réseau entier. Deux ou trois personnes nommément identifiées suffisent ; les comptes de service et les agences reçoivent des rôles d’administrateur sur des sous-sites.
3. Imposer l’authentification à deux facteurs aux rôles privilégiés. D’abord les super admins, ensuite les administrateurs des sous-sites. Des méthodes résistantes à l’hameçonnage comme les passkeys et clés de sécurité matérielles protègent les comptes dont la perte coûte le plus cher.
4. Gérer extensions et thèmes de façon centrale. WordPress empêche déjà les administrateurs de sous-sites d’installer des extensions. Gardez ce réglage. Vérifiez quelles extensions sont activées sur le réseau et lesquelles le sont site par site, puis supprimez tout ce qu’aucun sous-site n’utilise plus : les fichiers d’une extension désactivée restent du code accessible.
5. Désactiver l’édition de fichiers dans le tableau de bord. Définissez DISALLOW_FILE_EDIT dans le fichier de configuration pour qu’une session d’administration détournée ne puisse pas transformer l’éditeur de thème en shell PHP. Sur les réseaux gérés avec un pipeline de déploiement, DISALLOW_FILE_MODS bloque en plus toute installation et toute mise à jour depuis le navigateur.
6. Restreindre les téléversements. Les réglages du réseau fixent les types de fichiers autorisés et un quota de stockage par sous-site. Plus la liste des types autorisés est courte, moins il existe de moyens de glisser du contenu exécutable dans le dossier des téléversements.
7. Supprimer les sous-sites abandonnés. Chaque sous-site est une page de connexion, un point d’accès XML-RPC et un espace de noms de l’API REST. Si personne n’entretient plus un sous-site, archivez-le ou supprimez-le. La surface d’attaque disparaît avec lui.
8. Servir un TLS valide partout. Les installations en sous-domaines ont besoin d’un certificat wildcard, et chaque domaine personnalisé associé doit être couvert. Un seul sous-site en HTTP simple expose des cookies de session valables sur tout le réseau.
9. Mettre à jour entièrement depuis l’administration du réseau. Mettre à jour « seulement les sous-sites importants » n’existe pas. Tous exécutent les mêmes fichiers. Une extension laissée obsolète parce qu’un sous-site dépend de l’ancienne version garde le code vulnérable chargé pour tout le monde.
10. Centraliser la détection et le blocage. Les attaques distribuées sont invisibles dans les journaux de chaque site. Une vue commune des tentatives, des blocages et des événements des capteurs sur tous les sous-sites fait la différence entre voir une campagne et voir trente nuisances sans lien apparent.

La documentation officielle de WordPress sur le durcissement couvre les bases des droits sur les fichiers et de la configuration, valables pour toute installation ; les points ci-dessus ajoutent ce que le Multisite exige en plus.

Comment auditer un réseau existant en cinq commandes

Avant de modifier quoi que ce soit, mesurez l’état actuel. Sur un serveur équipé de WP-CLI, cinq commandes répondent aux questions par lesquelles commence tout audit de sécurité d’un WordPress Multisite :

• wp site list --fields=blog_id,url,last_updated : chaque sous-site avec sa dernière modification de contenu. Les sous-sites inchangés depuis un an sont candidats au point 7 de la liste.
• wp super-admin list : les comptes qui peuvent tout faire, partout. Si cette liste vous surprend, corrigez-la aujourd’hui.
• wp plugin list --fields=name,status,update : extensions activées sur le réseau, extensions activées site par site et mises à jour en attente dans une seule vue. Tout ce qui apparaît comme inactif reste du code sur le disque.
• wp user list --role=administrator --url=SUBSITE-URL : pour chaque sous-site, qui détient le rôle d’administrateur. Lancez la commande pour chaque sous-site et comparez avec les personnes qui y travaillent réellement.
• wp core verify-checksums : compare chaque fichier du cœur aux sommes de contrôle officielles de WordPress et signale les fichiers ajoutés ou modifiés. Un résultat propre écarte la méthode de persistance la plus courante après une intrusion.

Refaites l’audit après chaque changement de structure du réseau : un nouveau sous-site, une nouvelle agence avec un accès administrateur, un nouveau domaine associé. La liste des super admins et celle des sous-sites abandonnés sont les deux résultats qui changent le plus souvent d’un audit à l’autre.

Pourquoi les extensions de sécurité site par site échouent sur un réseau

La plupart des extensions de sécurité WordPress ont été conçues pour des sites isolés. Installées sur un Multisite, elles gardent en général leurs compteurs de tentatives, leurs listes de blocage et leurs journaux dans des tables propres à chaque sous-site. Chaque sous-site se défend seul.

Ce modèle cède face à l’attaque la moins coûteuse qui soit. Un attaquant qui répartit quatre tentatives de connexion sur chacun de dix sous-sites reste sous chaque seuil par site, tout en essayant quarante mots de passe contre la même table d’utilisateurs. Aucun sous-site ne voit assez d’activité pour réagir, donc aucun blocage n’est posé nulle part.

Le second échec est opérationnel : trente sous-sites, ce sont trente écrans de journaux séparés. En pratique, personne ne les lit, et c’est pourquoi les sous-sites compromis des grands réseaux sont si souvent découverts par des tiers plutôt que par l’exploitant.

Comment ReportedIP Hive partage un seul état de menace sur tout le réseau

ReportedIP Hive réunit 16 capteurs d’attaque, quatre méthodes 2FA, un blocage progressif et des renseignements communautaires sur les menaces, activés sur option. Il gère pleinement le Multisite depuis la version 2.0, et la version actuelle est la 2.1.67. Sur un réseau, l’extension ne peut être activée qu’à l’échelle du réseau ; WordPress masque le lien d’activation par site. L’interface de Hive est en anglais, les libellés cités dans ce guide restent donc en anglais.

Hive conserve ses données une seule fois pour tout le réseau au lieu d’une fois par sous-site, et le journal des événements note de quel sous-site provient chaque événement. Le résultat est un état de menace commun : les échecs de connexion d’une même IP sur différents sous-sites s’additionnent dans un compteur central, et un seul blocage exclut l’IP de tous les sous-sites à la fois. L’attaquant distribué de l’exemple ci-dessus atteint le seuil du réseau après quelques tentatives, au lieu de ne jamais l’atteindre.

Le même regroupement vaut pour les autres capteurs : abus de XML-RPC, limitation du débit REST, défense contre l’énumération des utilisateurs, détection des scanners 404 et le pare-feu applicatif qui inspecte les requêtes comptent par IP et par réseau, pas par sous-site. Les réponses de blocage sont compatibles avec le cache : une extension de cache ne peut pas servir de HTML stocké à une adresse bloquée sur les chemins protégés.

Les réseaux en mode Community Network vérifient en plus les visiteurs à l’aide de renseignements partagés : au 26 septembre 2026, la liste noire ReportedIP recense 30 926 IP à haut niveau de confiance. Une adresse qui a attaqué d’autres sites de la communauté peut ainsi être refusée avant son premier essai de mot de passe. Les réseaux qui doivent rester totalement hors ligne utilisent le mode Local Shield et conservent tous les mécanismes décrits ici, sauf les données de réputation partagées.

Ce que contrôlent les super admins et les administrateurs de site

Les super admins gèrent les réglages dans l’administration du réseau, et Hive leur impose par défaut la configuration de la 2FA. Les administrateurs d’un sous-site disposent d’une vue en lecture seule des pages Status et Logs (avec, dans la formule Business, le journal d’audit de leur propre site) et d’une page de réglages modifiable avec deux options : les slugs des pages 2FA du frontend WooCommerce, et des rôles supplémentaires soumis à la 2FA. Un administrateur de site peut ajouter un rôle à l’obligation de 2FA, mais pas retirer un rôle exigé par le réseau. Le confort d’un sous-site peut durcir la règle, jamais l’assouplir.

Le cookie des appareils de confiance vaut pour le chemin de cookie du réseau : une seule confirmation « faire confiance à cet appareil » s’applique à tous les sous-sites, sans nouvelle demande sur chacun. Les tâches planifiées ne tournent que sur le site principal, si bien qu’un réseau de cinquante sous-sites n’exécute pas cinquante tâches de nettoyage.

Faire entrer un site existant dans un réseau protégé

Les tables de l’extension sur un site isolé utilisent déjà le préfixe du réseau, l’historique des événements est donc conservé quand le site devient un réseau. Après la conversion, activez Hive sur le réseau et vérifiez une fois les réglages dans l’administration du réseau. Le comportement en site isolé comme en Multisite est couvert par des suites PHPUnit exécutées à chaque commit.

Ce que coûte une protection à l’échelle du réseau

Le cœur de détection est gratuit dans toutes les formules : capteurs, protection de base du pare-feu, blocage progressif et méthodes 2FA principales fonctionnent sur tout le réseau sans frais. Les formules payantes ajoutent les relais gérés et le confort d’un tableau de bord multi-domaines : 3 domaines en Professional, 15 en Business et une limite sur mesure en Enterprise ; un réseau Multisite entier compte pour un seul domaine. Le détail des formules figure sur la page produit de l’extension.

Questions fréquentes

Un sous-site piraté compromet-il tout le réseau WordPress ?

Un sous-site piraté signifie en général un réseau piraté. Tous les sous-sites partagent une base de code, une base de données et une table d’utilisateurs, et tournent dans le même processus PHP. Une exécution de code ou une injection SQL sur n’importe quel sous-site atteint les données du réseau, c’est pourquoi le durcissement d’un Multisite traite chaque sous-site comme une partie d’un seul périmètre.

Faut-il activer les extensions de sécurité sur tout le réseau Multisite ?

Une protection que chaque administrateur de site peut désactiver n’est pas une règle de réseau, une extension de sécurité doit donc être activée sur le réseau. ReportedIP Hive l’impose par conception : sur un Multisite, il ne peut être activé qu’à l’échelle du réseau, et aucun sous-site ne peut se soustraire à la surveillance ou au blocage.

Combien de super admins un réseau Multisite devrait-il avoir ?

Aussi peu que l’exploitation le permet, en général deux ou trois personnes nommément identifiées. Chaque super admin passe chaque contrôle de droits sur chaque sous-site, donc chaque compte supplémentaire multiplie le risque d’hameçonnage pour tout le réseau. Tous devraient utiliser une authentification à deux facteurs résistante à l’hameçonnage.

Un blocage d’IP s’applique-t-il à tous les sous-sites ?

Un blocage s’applique à tout le réseau lorsque l’extension de sécurité l’enregistre une seule fois pour le réseau. Dans ReportedIP Hive, un seul blocage exclut l’IP de chaque sous-site en même temps, et les tentatives sur différents sous-sites s’additionnent dans un seul compteur. Un botnet qui saute d’un sous-site à l’autre compte comme une seule campagne.

À lire ensuite

• Local Shield ou Community Network sur un réseau
• Le blocage progressif appliqué au réseau
• Démarrage rapide avec l’assistant de configuration

La documentation de Hive détaille les réseaux Multisite et l’authentification à deux facteurs. Retrouvez les autres fonctions dans tous les guides de ReportedIP Hive.

Découvrir ReportedIP Hive →