Que faire le jour où une vulnérabilité de plugin WordPress est publiée

Une nouvelle vulnérabilité de plugin WordPress est publiée presque chaque jour. La plupart ne demandent rien de plus que la prochaine mise à jour habituelle. Quelques-unes demandent d’agir aujourd’hui : celles qui sont activement exploitées, qui ne nécessitent aucune connexion, ou qui touchent un plugin installé sur des dizaines de sites clients. Ce guide est une routine pour ce jour-là : comment décider vite si une faille vous concerne, comment trouver chaque site touché et quoi faire après la mise à jour.

Étape 1 : décider en cinq minutes si c’est urgent

Lisez l’avis lui-même (Patchstack, Wordfence ou WPScan), pas seulement le titre. Quatre questions déterminent la vitesse à laquelle vous agissez :

• Est-elle exploitée ? Un avis qui signale des attaques observées passe en tête de votre journée.
• Faut-il une connexion ? Une faille qu’un visiteur anonyme peut utiliser est bien plus dangereuse qu’une faille qui exige un compte administrateur.
• Que peut faire un attaquant ? Téléverser des fichiers, exécuter du code ou créer des comptes administrateur est pire qu’un XSS réfléchi qui demande un clic.
• Sur combien de vos sites tourne-t-il ? Un site, c’est une tâche ; quarante sites, c’est un projet avec une échéance.

Si la réponse aux deux premières questions est oui, traitez-la comme urgente : les sites touchés aujourd’hui, pas à la prochaine tournée de maintenance.

Étape 2 : trouver chaque site touché

Il vous faut deux informations par site : le plugin est-il installé (actif ou non), et en quelle version. Les plugins inactifs comptent aussi. Le code vulnérable reste sur le serveur et est souvent encore accessible directement.

Avec WP-CLI, cela prend quelques secondes par site :

wp plugin list --name=ninja-forms --fields=name,status,version

Sans WP-CLI, regardez dans Extensions dans wp-admin, ou la version dans le readme.txt du plugin. Notez le résultat dans une seule liste : site, installé oui ou non, version, version corrigée. Cette liste est votre checklist pour le reste de la journée et votre preuve pour le client ensuite.

Étape 3 : mettre à jour les sites touchés, les plus exposés d’abord

Commencez par les sites qui comptent le plus s’ils sont touchés : boutiques en ligne, sites avec beaucoup de formulaires ou de comptes utilisateurs, et sites à fort trafic. Avant chaque mise à jour, assurez-vous qu’une sauvegarde récente existe et que vous pouvez vraiment la restaurer.

Les mises à jour de sécurité sont généralement petites, mais pas toujours. Certains éditeurs livrent le correctif dans une version plus large avec d’autres changements. Si la version corrigée est un grand saut, ou si le plugin gère des formulaires ou le paiement, testez-la d’abord sur une copie du site quand c’est possible, puis vérifiez les pages clés.

Si vous ne pouvez pas mettre à jour aujourd’hui, par exemple parce que le correctif n’est pas encore publié ou que la mise à jour casse quelque chose, réduisez plutôt le risque : désactivez le plugin si le site peut s’en passer une journée, ou bloquez le point d’accès vulnérable dans votre pare-feu si l’avis le mentionne. Dites au client ce que vous avez fait et pourquoi.

Étape 4 : tester ce que fait le plugin

Une mise à jour réussie n’est pas la même chose qu’un site qui fonctionne. Après la mise à jour, testez ce à quoi sert le plugin. Pour un plugin de formulaire, envoyez un vrai test et vérifiez que l’e-mail arrive. Pour un plugin de boutique, passez une commande test jusqu’au paiement. Un formulaire qui cesse d’envoyer sans bruit peut coûter à un client une semaine de demandes avant que quelqu’un ne s’en aperçoive.

Étape 5 : vérifier si le site a déjà été touché

La mise à jour bouche le trou. Elle ne supprime rien de ce qu’un attaquant a laissé avant. Si la faille a été exploitée avant votre correctif, vérifiez sur chaque site touché :

• des comptes administrateur que vous ne reconnaissez pas ;
• des fichiers PHP dans le dossier uploads, qui ne devrait contenir que des médias ;
• des fichiers récemment modifiés dans des plugins et thèmes que vous n’avez pas mis à jour ;
• des tâches planifiées inconnues, ou des redirections que vous n’avez pas créées.

Si vous trouvez des signes de compromission, restaurez une sauvegarde antérieure à la période d’attaque, mettez à jour immédiatement et changez tous les mots de passe ainsi que les clés de sécurité dans wp-config.php. Corriger seul ne suffit pas.

Étape 6 : informer le client, brièvement

Les clients lisent rarement l’actualité de la sécurité, mais ils remarquent quand leur agence a suivi le sujet. Un court message suffit : quel était le problème, si leur site était touché ou non, ce que vous avez fait et quand. Une tâche invisible devient une valeur visible, et elle a aussi sa place dans votre prochain rapport de maintenance.

Aller plus vite la prochaine fois

• Tenez une liste des plugins installés sur chaque site, pour que l’étape 2 prenne quelques minutes.
• Suivez une ou deux sources d’avis, pas dix.
• Assurez-vous que chaque site a une sauvegarde que vous avez vraiment restaurée au moins une fois.
• Convenez à l’avance avec vos clients que les mises à jour de sécurité urgentes se font en dehors du calendrier habituel.

Comment Verploy gère les vulnérabilités de plugins

Verploy affiche les vulnérabilités connues dans les plugins et thèmes de chaque site connecté, pour que vous voyiez tout de suite quels sites sont touchés. Chaque mise à jour est vérifiée, et les plus risquées sont d’abord testées sur une copie, formulaires et paiement compris. Les sauvegardes nocturnes s’accompagnent d’un test de restauration, et si un site casse après la mise en ligne, Verploy revient en arrière. En savoir plus sur la surveillance des vulnérabilités WordPress.