L’agence qui nous a sollicités pour cet audit gère un portefeuille de soixante-trois sites WordPress pour différents clients, hébergés sur des infrastructures variées : certains sur un serveur mutualisé propre à l’agence, d’autres chez des hébergeurs choisis par les clients eux-mêmes des années plus tôt. Un correctif de sécurité avait été publié par l’éditeur d’une extension de formulaires très répandue, corrigeant une faille permettant une élévation de privilèges via une action AJAX mal protégée. L’avis avait été relayé par Patchstack et WPScan dès sa publication, six mois avant l’audit.
L’inventaire réalisé pendant l’audit a montré que quarante-sept des soixante-trois sites tournaient encore avec la version vulnérable, six mois après la sortie du correctif. Aucun de ces sites n’avait été compromis au moment de l’intervention, un simple coup de chance étant donné le niveau de gravité de la faille, mais l’exposition était bien réelle et documentée publiquement depuis plusieurs mois.
Une automatisation qui ne couvrait qu’une partie du parc
L’agence avait pourtant mis en place une politique de mises à jour automatiques, activée via le filtre auto_update_plugin sur l’ensemble des sites qu’elle gérait directement. Le problème est venu de la définition même de « gérer directement » : cette politique n’était appliquée qu’aux sites hébergés sur l’infrastructure propre de l’agence, où un script de provisioning standard activait systématiquement les mises à jour automatiques des extensions au moment de la création du site. Les sites hébergés ailleurs, repris en cours de route auprès d’un client ou d’une autre agence, n’avaient jamais reçu cette configuration.
Sur ces sites orphelins de la politique, les mises à jour automatiques des extensions restaient dans leur état par défaut, souvent désactivées ou limitées aux seules mises à jour mineures selon la configuration héritée de l’installation d’origine. Personne, côté agence, n’avait de vue d’ensemble sur lesquels de ses soixante-trois sites appliquaient réellement la politique décidée, faute d’inventaire centralisé fiable.
Reconstituer la cartographie réelle du parc
La première étape de l’audit a consisté à établir, site par site, l’état réel des mises à jour automatiques, plutôt que de se fier à ce que la documentation interne de l’agence affirmait. Cette vérification s’automatise facilement avec WP-CLI, en boucle sur la liste des sites :
#!/bin/bash
while read -r site; do
echo "=== $site ==="
ssh "$site" "wp plugin list --update=available --format=csv" 2>/dev/null
ssh "$site" "wp option get auto_update_plugins" 2>/dev/null
done < liste-sites.txtCette commande a révélé une hétérogénéité que personne n’avait mesurée jusque-là : sur les soixante-trois sites, quatre configurations différentes coexistaient, allant de la mise à jour automatique totale (cœur, thèmes, extensions) à l’absence complète d’automatisation, sans qu’aucun document interne ne recense cette répartition. C’est cette absence de cartographie centralisée, bien plus que la faille elle-même, qui constitue le véritable point de défaillance mis au jour par l’audit.
Pourquoi les mises à jour automatiques partielles créent un faux sentiment de sécurité
Le paradoxe de cette situation est que l’agence, en tant qu’organisation, pouvait légitimement affirmer avoir « une politique de mises à jour automatiques ». Cette affirmation était vraie pour une partie du parc et fausse pour le reste, ce qui la rend dangereuse : elle rassure sans couvrir la réalité. Ce phénomène se retrouve fréquemment dans les organisations qui gèrent plusieurs dizaines de sites accumulés au fil de reprises de clientèle, de fusions d’agences, ou de changements d’hébergeur, sans qu’un inventaire n’ait jamais été formellement mis à jour pour englober les nouveaux arrivants.
- Une politique de mise à jour n’a de valeur que si elle s’applique de façon vérifiable à cent pour cent du parc, pas à la majorité.
- Un site repris auprès d’un tiers doit systématiquement faire l’objet d’un audit de configuration avant d’être considéré comme « couvert » par les politiques internes.
- Un inventaire déclaratif (« on met à jour automatiquement ») ne remplace jamais un inventaire vérifié par une commande exécutée sur chaque site.
Mettre en place une vérification centralisée
Le correctif structurel mis en place après cet audit ne repose pas sur un outil miracle, mais sur une routine simple exécutée chaque semaine, indépendamment de la politique de mise à jour choisie site par site : un script recense la version de chaque extension installée sur l’ensemble du parc, la compare à un flux d’avis de sécurité publics (Patchstack, WPScan), et remonte une alerte pour tout site où une version vulnérable connue reste active plus de soixante-douze heures après la publication du correctif.
wp plugin list --format=json | jq -r '.[] | select(.update=="available") | .name'Cette commande, exécutée site par site via une boucle de supervision, alimente désormais un tableau de bord commun à toute l’agence, indépendant de la configuration d’automatisation propre à chaque hébergement. Peu importe qu’un site mette à jour tout seul ou non : l’alerte remonte de toute façon si une version vulnérable traîne.
Une politique de mise à jour qui ne s’applique qu’à une partie du parc n’est pas une politique incomplète, c’est une politique qui n’existe pas encore vraiment.
Ce que ça révèle sur les limites du choix d’automatisation
Cet audit n’a pas remis en cause le choix d’activer ou non les mises à jour automatiques sur tel ou tel site, une décision qui dépend légitimement du niveau de tests de non-régression que chaque client peut supporter. Ce qu’il a révélé, c’est qu’aucune politique de sécurité, quelle qu’elle soit, ne vaut mieux que la fiabilité de son inventaire. Six mois d’exposition à une faille publiquement documentée ne provenaient pas d’un mauvais choix technique, mais d’un angle mort organisationnel : personne, à aucun moment, n’avait de vue fiable sur l’ensemble du parc pour vérifier que la politique décidée s’appliquait réellement partout.
