Sécurité WordPress Multisite : guide de renforcement de la sécurité du réseau

La sécurité d’un site WordPress Multisite présente des failles différentes de celles d’un site unique : une base de code partagée, une base de données unique et une table d’utilisateurs globale signifient qu’un seul sous-site vulnérable peut permettre à un attaquant d’accéder à l’ensemble du réseau. Ce guide présente le modèle de menace Multisite, une liste de contrôle en 10 points pour renforcer la sécurité, et explique pourquoi le blocage à l’échelle du réseau comble la faille laissée ouverte par les outils de sécurité spécifiques à chaque site.

Pourquoi la sécurisation d’un réseau Multisite diffère-t-elle de celle d’un site unique ?

Un réseau Multisite WordPress ressemble à un ensemble de sites web, mais, d’un point de vue structurel, il s’agit d’une seule et même installation. Cinq caractéristiques définissent son modèle de menace :

Une seule base de code. Chaque sous-site utilise le même noyau WordPress, les mêmes fichiers de plugins et les mêmes fichiers de thème à partir d’un seul répertoire. Une vulnérabilité présente dans un seul plugin peut être exploitée sur tous les sous-sites où ce plugin est activé.
Une seule base de données. Les sous-sites disposent chacun de leurs propres ensembles de tables, mais il n’existe aucune barrière de privilèges entre eux. Une SQL Injection sur n’importe quel sous-site affecte toutes les tables de la base de données, y compris les tables réseau.
Utilisateurs globaux. La table des utilisateurs est partagée sur l’ensemble du réseau. Un compte créé sur un sous-site existe partout, et des identifiants volés sur le sous-site le moins important peuvent être utilisés contre le plus important.
Un seul processus PHP. Tous les sous-sites sont hébergés par le même serveur d’applications, avec les mêmes droits d’accès aux fichiers. L’exécution de code sur un sous-site équivaut à l’exécution de code sur l’ensemble du réseau.
Le rôle de super-administrateur. Les super-administrateurs satisfont à tous les contrôles d’autorisation sur chaque sous-site. Il n’y a pas de compromission partielle d’un compte de super-administrateur : le Phishing de l’un d’entre eux entraîne la perte de l’ensemble du réseau.

Conséquence concrète : le niveau de sécurité d’un réseau Multisite correspond à celui de son site le plus vulnérable. Un site de test oublié, équipé d’un plugin obsolète, n’est pas un simple risque mineur isolé : c’est une porte d’entrée vers l’ensemble du réseau.

Quels sont les éléments d’un réseau Multisite que les pirates sondent en premier ?

Entre mai et juillet 2026, le Community Network ReportedIP a recensé 1,69 million d’attaques contre des sites WordPress, les Endpoints de Login constituant la cible principale. Sur les sites Multisite, plusieurs de ces Endpoints se multiplient en fonction du nombre de sous-sites :

Surface d’attaque	Pourquoi c’est encore plus important dans le cadre d’un site Multisite	Première mesure de riposte
`wp-signup.php`	L’inscription libre permet aux bots de créer des comptes, voire des sous-sites entiers, sur l’ensemble du réseau.	Dans les paramètres réseau, définissez l’option « Enregistrement » sur « désactivé » ou « comptes utilisateur uniquement ».
Pages de Login	Chaque sous-site affiche son propre formulaire de Login, et tous s’appuient sur la même table d’utilisateurs partagée pour l’authentification.	Surveillance du Login à l’échelle du réseau avec des compteurs de tentatives partagés.
`xmlrpc.php`	Il n’en existe qu’un par sous-site ; chaque instance accepte les tentatives d’authentification et les requêtes « multicall » amplifiées.	Désactivez-le à l’échelle du réseau ou limitez-le de manière centralisée.
User Enumeration REST	Les endpoints « utilisateurs » permettent de connaître les noms d’utilisateur à l’échelle du réseau : une seule requête permet de répertorier tous les comptes du réseau.	Bloquer l’User Enumeration pour les requêtes non authentifiées.
Sous-sites obsolètes	Les sous-sites abandonnés continuent d’exécuter l’intégralité du code source, mais personne ne consulte leurs journaux.	Supprimez ou archivez les sous-sites qui ne sont plus mis à jour.
Domaines mappés	Un domaine mappé sans TLS valide expose les cookies d’authentification partagés du réseau.	Assurez-vous que chaque sous-site et chaque domaine mappé dispose d’un certificat valide.

Une liste de contrôle en 10 points pour renforcer la sécurité d’un site WordPress Multisite

Suivez ces étapes dans l’ordre. Les points 1 à 3 permettent d’éliminer les risques les plus graves ; les points 4 à 9 réduisent la surface d’attaque ; le point 10 concerne la détection.

Fermer ou restreindre les inscriptions. Le paramètre « Inscription » dans l’interface d’administration du réseau détermine si des personnes extérieures peuvent créer des comptes ou des sous-sites. Si les inscriptions doivent rester ouvertes, activez le Disposable-Email Blocking et mettez en place un « Honeypot » d’inscription afin que les inscriptions effectuées par des robots échouent avant de générer une charge excessive.
Limitez au strict minimum la liste des super-administrateurs. Si un compte de super-administrateur est victime d’une attaque de Phishing, cela compromet l’intégrité du réseau tout entier. Deux ou trois personnes désignées suffisent ; les comptes de service et les agences devraient plutôt se voir attribuer des rôles d’administrateur de sous-site.
Imposer l’authentification à deux facteurs pour les rôles privilégiés. En priorité pour les super-administrateurs, puis pour les administrateurs de sous-sites. Les méthodes résistantes au Phishing, telles que les Passkeys et les Hardware Security Keys, protègent les comptes dont la perte serait la plus coûteuse.
Gérez les plugins et les thèmes de manière centralisée. WordPress empêche déjà les administrateurs des sous-sites d’installer des plugins — veillez à ce que cela reste ainsi. Vérifiez quels plugins sont activés au niveau du réseau et lesquels sont activés de manière sélective, puis supprimez tout ce qui n’est plus utilisé par aucun sous-site : les fichiers des plugins désactivés restent du code accessible.
Désactivez la modification des fichiers dans le Dashboard. Définissez DISALLOW_FILE_EDIT dans le fichier de configuration afin qu’une session d’administrateur piratée ne puisse pas transformer l’éditeur de thème en shell PHP. Sur les réseaux gérés dotés d’un pipeline de déploiement, DISALLOW_FILE_MODS bloque également complètement les installations et les mises à jour via le navigateur.
Limiter les téléchargements. Les paramètres réseau permettent de contrôler les types de fichiers autorisés au téléchargement ainsi que le quota de stockage par site. Des Allowlists plus restreintes réduisent les possibilités d’introduire clandestinement du contenu exécutable dans l’arborescence des fichiers téléchargés.
Supprimez les sous-sites obsolètes. Chaque sous-site correspond à une page de connexion, à un Endpoint XML-RPC et à un espace de noms de REST API. Si aucun sous-site n’est entretenu, archivez-le ou supprimez-le : la surface d’attaque disparaîtra avec lui.
Utilisez le protocole TLS partout. Les installations sur des sous-domaines nécessitent un certificat générique ; chaque domaine personnalisé mappé doit être couvert. Un simple sous-site fonctionnant en HTTP standard expose des cookies de session valables sur l’ensemble du réseau.
Mettez à jour depuis l’administration du réseau, complètement. il n’est pas question de mettre à jour « uniquement les sous-sites importants » — tous utilisent les mêmes fichiers. Un plugin qui reste obsolète parce qu’un sous-site dépend de l’ancienne version fait en sorte que le code vulnérable reste chargé pour tout le monde.
Centralisez la détection et le blocage. Les attaques distribuées passent inaperçues dans les journaux propres à chaque site. Une vue d’ensemble commune des tentatives, des blocages et des événements détectés par les capteurs sur l’ensemble des sous-sites fait toute la différence entre identifier une campagne et percevoir trente incidents sans rapport les uns avec les autres.

La documentation officielle sur le renforcement de la sécurité de WordPress aborde les principes de base relatifs aux droits d’accès aux fichiers et à la configuration qui s’appliquent à toute installation ; les points mentionnés ci-dessus constituent les éléments supplémentaires propres au mode Multisite.

Comment auditer un réseau existant en cinq commandes

Avant d’apporter la moindre modification, évaluez la situation actuelle. Sur un serveur équipé de WP-CLI, cinq commandes permettent de répondre aux questions qui marquent le début de tout audit de sécurité d’un site WordPress Multisite :

wp site list --fields=blog_id,url,last_updated — chaque sous-site avec la date de sa dernière mise à jour. Les sous-sites qui n’ont pas été modifiés depuis un an sont concernés par le point 7 de la liste de contrôle.
wp super-admin list — les comptes qui permettent de tout faire, où que vous soyez. Si cette liste vous surprend, remédiez-y dès aujourd’hui.
wp plugin list --fields=name,status,update — les plugins activés par le réseau, les plugins activés de manière sélective et les mises à jour en attente, le tout dans une seule vue. Tout ce qui est répertorié comme inactif reste du code présent sur le disque.
wp user list --role=administrator --url=SUBSITE-URL — par sous-site, qui occupe le rôle d’administrateur. Effectuez cette vérification pour chaque sous-site et comparez les résultats avec les personnes qui y travaillent réellement.
wp core verify-checksums — compare chaque fichier du cœur du système aux sommes de contrôle officielles de WordPress et signale les fichiers qui ont été ajoutés ou modifiés. Un résultat « propre » permet d’écarter la méthode de persistance la plus courante après une intrusion.

Répétez l’audit après chaque modification structurelle apportée au réseau : ajout d’un nouveau sous-site, d’une nouvelle agence disposant d’un accès administrateur ou d’un nouveau domaine mappé. La liste des super-administrateurs et celle des sous-sites obsolètes sont les deux éléments qui évoluent le plus souvent d’un audit à l’autre.

Pourquoi les plugins de sécurité par site ne fonctionnent pas sur un réseau

La plupart des plugins de sécurité WordPress ont été conçus pour des sites uniques. Lorsqu’ils sont installés sur un réseau Multisite, ils conservent généralement leurs compteurs de tentatives, leurs listes de blocage et leurs journaux dans des tables de base de données propres à chaque site — chaque sous-site se défend donc seul.

Ce modèle ne résiste pas à l’attaque la plus simple qui soit. Un attaquant utilisant la Brute Force qui répartit quatre tentatives de Login sur chacun des dix sous-sites reste en dessous du seuil de cinq fixé par site, tout en effectuant quarante tentatives sur la même table d’utilisateurs partagée. Aucun sous-site ne détecte à lui seul une activité suffisante pour réagir, de sorte qu’aucun blocage n’est déclenché nulle part.

Le deuxième problème est d’ordre opérationnel : trente sous-sites impliquent trente écrans de journaux distincts. Dans la pratique, personne ne les consulte, ce qui explique pourquoi, sur les grands réseaux, ce sont souvent des personnes extérieures, et non l’opérateur, qui découvrent les sous-sites compromis.

Comment ReportedIP Hive partage un état de menace unique sur l’ensemble du réseau

ReportedIP Hive — 16 Attack Sensors, quatre méthodes d’authentification à deux facteurs (2FA), un blocage progressif et des informations sur la Threat Intelligence issues de la communauté (sur inscription) — prend entièrement en charge les sites Multisite depuis la version 2.0 ; la version actuelle est la 2.1.37. En mode Multisite, le plugin est activé uniquement au niveau du réseau ; l’activation par site est masquée par WordPress.

Toutes les tables de plugins sont gérées au niveau du réseau via $wpdb->base_prefix, avec une colonne blog_id indiquant où chaque événement s’est produit. Il en résulte un état de menace partagé : les échecs de Login provenant d’une même adresse IP sur différents sous-sites sont agrégés dans un compteur central de tentatives, et une seule entrée dans la table des adresses bloquées empêche l’accès de cette adresse IP à tous les sous-sites simultanément. L’attaquant distribué de l’exemple ci-dessus atteint le seuil dès sa quatrième tentative au total — au lieu de ne jamais le déclencher.

Le même principe d’agrégation s’applique aux autres capteurs : les abus XML-RPC, le Rate Limiting REST, la protection contre l’User Enumeration, la détection des scanners 404 et le Web Application Firewall inspectant les requêtes sont tous comptabilisés par adresse IP et par réseau, et non par sous-site. Les réponses bloquées ne posent aucun problème pour la mise en cache ; ainsi, un plugin de mise en cache ne peut pas servir de code HTML stocké à une adresse bloquée sur des chemins protégés.

Les réseaux fonctionnant en mode « Communauté » effectuent en outre une vérification des visiteurs à l’aide de données partagées : depuis juillet 2026, la ReportedIP Blacklist recense plus de 20 000 adresses IP considérées comme des menaces avec un niveau de confiance élevé ; ainsi, une adresse ayant attaqué d’autres sites de la communauté peut être bloquée avant même la première tentative de mot de passe. Les réseaux qui doivent rester entièrement hors ligne utilisent le mode « Local Shield » et conservent tous les mécanismes décrits ici, à l’exception des données de réputation partagées.

Ce que contrôlent respectivement les super-administrateurs et les administrateurs de site

Les super-administrateurs gèrent les paramètres réseau et sont soumis sans exception à la configuration de l’authentification à deux facteurs (2FA) — l’option reportedip_hive_2fa_enforce_super_admins est activée par défaut. Les administrateurs de sous-site disposent d’une vue en lecture seule sur l’état et les journaux, ainsi que d’une page de paramètres modifiable comportant exactement deux options de personnalisation : le slug du Frontend 2FA pour l’interface publique de chaque site, et les rôles d’application supplémentaires. Un administrateur de site peut ajouter un rôle à l’application de la 2FA, mais ne peut pas supprimer un rôle requis par le réseau — la flexibilité offerte par les sous-sites permet de renforcer la politique, mais jamais de l’assouplir.

Le cookie « Trusted Device » est limité au chemin d’accès réseau des cookies ; ainsi, une seule confirmation « faire confiance à cet appareil » s’applique à tous les sous-sites, ce qui évite d’avoir à la demander à nouveau sur chacun d’entre eux. Les tâches planifiées s’exécutent uniquement sur le site principal, protégé par is_main_site(), ce qui évite les exécutions cron en double pour chaque sous-site.

Migration d’un site unique existant vers un réseau protégé

Une installation Hive mono-site qui intègre un réseau est automatiquement migrée lors de la première intervention de l’administrateur. La seule modification apportée au schéma consiste en l’ajout d’une colonne blog_id dont la valeur par défaut est 1 — aucune donnée n’est déplacée ni réécrite. Des classes de service dédiées au schéma, à la migration et au routage des options gèrent chaque accès pertinent pour le mode Multisite, et les comportements en mode mono-site et Multisite sont tous deux couverts par des suites PHPUnit qui s’exécutent à chaque validation.

Quel est le coût d’une protection à l’échelle du réseau ?

Le cœur de détection est gratuit dans toutes les formules : les capteurs, la configuration de base du pare-feu, le blocage progressif et les principales méthodes d’authentification à deux facteurs (2FA) fonctionnent à l’échelle du réseau sans frais supplémentaires. Les formules payantes offrent en plus la gestion des relais et la commodité d’un Dashboard multi-domaines : 3 domaines pour la formule Professional, 15 pour la formule Business et une limite personnalisable pour la formule Enterprise. Les détails des formules sont disponibles sur la page produit du plugin.

Foire aux questions

Le Hacking d’un sous-site compromet-il l’ensemble du réseau WordPress ?

Dans la pratique, oui. Tous les sous-sites partagent une seule base de code, une seule base de données et une seule table d’utilisateurs, et ils s’exécutent au sein du même processus PHP. L’exécution de code ou une SQL Injection sur n’importe quel sous-site permet d’accéder aux données du réseau ; c’est pourquoi le renforcement de la sécurité Multisite considère chaque sous-site comme faisant partie d’un même périmètre.

Faut-il activer les plugins de sécurité au niveau du réseau sur un site Multisite ?

Oui — une protection que les administrateurs de chaque site peuvent désactiver ne constitue pas une politique réseau. ReportedIP Hive garantit cette contrainte par conception : dans un environnement Multisite, cette fonctionnalité ne peut être activée qu’au niveau du réseau, de sorte qu’aucun sous-site ne peut se soustraire à la surveillance ou au blocage.

Combien de super-administrateurs un réseau Multisite devrait-il compter ?

Aussi peu que l’opération le permette — généralement deux ou trois personnes désignées. Chaque super-administrateur passe avec succès tous les contrôles de capacité sur chaque sous-site ; ainsi, chaque compte supplémentaire multiplie le risque de Phishing pour l’ensemble du réseau. Tous doivent utiliser une authentification à deux facteurs résistante au Phishing.

Une même restriction d’adresse IP s’applique-t-elle à tous les sous-sites ?

Avec les tables au niveau du réseau, oui. Dans ReportedIP Hive, une seule ligne de la table des adresses bloquées bloque simultanément l’adresse IP sur tous les sous-sites, et les tentatives visant différents sous-sites sont regroupées dans un seul compteur : un botnet passant d’un sous-site à l’autre est ainsi comptabilisé comme une seule campagne.

Guides connexes

La documentation du plugin WordPress traite en détail de la configuration du réseau. Consultez l’intégralité des guides du plugin ReportedIP Hive ou consultez le code source sur GitHub.

Découvrez la rubrique « ReportedIP Hive » →

Sécurité WordPress Multisite : le guide pour renforcer la sécurité du réseau