Vulnérabilité WordPress découverte : comment réagir vite et bien
Quand une faille est rendue publique, la course contre les robots commence. Dès la publication d'une vulnérabilité sur une extension WordPress populaire, des scripts automatisés cherchent les sites qui ne sont pas encore corrigés. Cet article vous explique comment évaluer le risque, appliquer le correctif sans casser le site, vérifier que personne n'est déjà entré et organiser votre veille pour la prochaine fois.
Comprendre une vulnérabilité WordPress
Une vulnérabilité est une erreur dans le code d'un logiciel qui permet à quelqu'un de faire ce qu'il ne devrait pas pouvoir faire : lire des données, modifier des pages, créer un compte, exécuter du code sur votre serveur. Sur WordPress, l'immense majorité des failles recensées par les bases publiques comme WPScan ou Patchstack concerne les extensions et les thèmes, bien plus que le cœur du logiciel.
Chaque faille reçoit en général un identifiant CVE, une référence internationale, et un score de gravité appelé CVSS. Le développeur publie un correctif, souvent en même temps que l'annonce. C'est là que le danger devient concret : l'annonce documente le problème, et les attaquants peuvent analyser le correctif pour comprendre comment exploiter les sites restés en arrière.
L'erreur fréquente est de penser qu'un petit site n'intéresse personne. Les attaques ne visent pas un site en particulier : elles balayent tout le web à la recherche d'une version précise d'une extension. Un site vitrine est attaqué exactement comme une grande boutique, simplement parce qu'il répond à la requête.
Autre erreur : croire que la mise à jour règle tout. Si la faille a été exploitée avant votre correction, l'attaquant a pu installer une porte dérobée qui survivra à la mise à jour. Corriger et vérifier sont deux étapes distinctes.
Le délai est donc l'enjeu central. Entre la publication d'une faille et l'application du correctif sur votre site, une fenêtre d'exposition s'ouvre. Pour un site mis à jour automatiquement, elle se compte en heures. Pour un site mis à jour « quand on y pense », elle se compte en semaines, voire en mois. C'est précisément dans cette fenêtre que se produisent la plupart des piratages automatisés. Réduire ce délai, par l'automatisation ou par une organisation claire, est la mesure la plus rentable que vous puissiez prendre face aux vulnérabilités.
Les enjeux : évaluer le niveau d'urgence
Toutes les failles ne se valent pas. Pour décider de la vitesse de réaction, posez-vous quatre questions :
- L'extension est-elle installée, et dans quelle version ? Une faille corrigée dans la version que vous utilisez déjà ne vous concerne pas.
- Faut-il être connecté pour l'exploiter ? Une faille accessible à un visiteur anonyme est beaucoup plus dangereuse qu'une faille qui exige un compte administrateur.
- Quel est l'impact ? Exécution de code à distance, création de compte ou injection SQL sont critiques. Une faille qui révèle une information mineure l'est moins.
- Est-elle déjà exploitée ? Les éditeurs de sécurité signalent les failles activement exploitées. Dans ce cas, chaque heure compte.
Une faille non authentifiée, à fort impact et déjà exploitée se traite dans la journée, même un week-end. Une faille qui exige un rôle d'administrateur sur un site où vous êtes seul administrateur peut attendre la prochaine fenêtre de maintenance, à condition qu'elle soit proche.
Où suivre les vulnérabilités
Plusieurs sources publiques recensent les failles WordPress et les rendent consultables : la base WPScan, Wordfence Intelligence et Patchstack pour l'écosystème WordPress, ainsi que les bulletins du CERT-FR pour les alertes les plus importantes. Pour un dirigeant, suivre ces sources au quotidien n'est pas réaliste. L'essentiel est que quelqu'un, en interne, chez votre prestataire ou via un outil, fasse le rapprochement entre les failles publiées et les composants réellement installés sur vos sites.
Le cas particulier du cœur de WordPress
Les failles du cœur de WordPress sont plus rares et traitées de façon particulière. Depuis la version 3.7, les versions mineures, qui contiennent les correctifs de sécurité, s'installent automatiquement par défaut. Il faut toutefois vérifier que ce mécanisme n'a pas été désactivé par un prestataire ou par l'hébergeur, et suivre les versions majeures, qui elles demandent une action. Un site bloqué sur une ancienne branche ne reçoit plus forcément de correctifs.
Cas concrets
L'association et son extension de formulaire
Le site d'une association sportive utilise une extension de formulaires très répandue. Une faille permettant d'envoyer des fichiers sans être connecté est publiée un vendredi. Le bénévole qui gère le site ne lit pas les alertes. Le lundi, un fichier PHP se trouve dans le dossier des téléversements. Une mise à jour automatique avec sauvegarde aurait fermé la porte le jour même.
La boutique WooCommerce prudente
Une boutique de vins apprend qu'une extension de paiement est vulnérable. Le gérant craint de casser le tunnel de commande. Il réalise une sauvegarde, applique la mise à jour sur une copie, teste une commande, puis met à jour la production en moins d'une heure. Il vérifie ensuite les comptes administrateurs et les fichiers modifiés récemment.
L'agence et ses quarante sites
Une agence apprend qu'un thème qu'elle utilise sur de nombreux sites clients contient une faille. Sans inventaire, elle ne sait pas lesquels sont concernés. Elle passe une journée à se connecter un par un. Depuis, elle tient un tableau de bord centralisé des versions installées sur chaque site.
Le cabinet et l'extension abandonnée
Un cabinet d'avocats utilise une extension de prise de rendez-vous qui n'est plus mise à jour. La faille publiée ne sera jamais corrigée. Seule solution : la remplacer par une extension maintenue et supprimer l'ancienne, base de données comprise.
Méthode pas à pas
- Vérifier si vous êtes concerné : relevez la version exacte de l'extension ou du thème sur chaque site. Avec WP-CLI, l'outil en ligne de commande de WordPress, une commande suffit :
wp plugin list --fields=name,status,version,update_version
wp theme list --fields=name,status,version,update_version
- Sauvegarder avant d'agir : fichiers et base de données, stockés hors de l'hébergement. C'est votre filet de sécurité si la mise à jour pose problème.
- Appliquer le correctif : mettez à jour l'extension vers la version corrigée. Pour une mise à jour majeure sur un site critique, testez d'abord sur une copie, comme expliqué dans notre article sur les mises à jour WordPress sans casser son site.
- Sans correctif, réduire l'exposition : désactivez puis supprimez l'extension si possible, ou bloquez l'accès aux fonctions vulnérables avec votre pare-feu applicatif.
- Chercher des traces d'intrusion : listez les administrateurs, les fichiers PHP dans le dossier uploads et les fichiers modifiés depuis la date de publication de la faille.
- Contrôler l'intégrité du cœur et des extensions : comparez les fichiers avec les versions officielles. En cas d'anomalie, suivez notre méthode pour supprimer un malware WordPress.
- Documenter : notez la faille, la date de correction et les vérifications faites. En cas d'incident ultérieur, ce journal vous fera gagner du temps.
Bonnes pratiques
- Tenez un inventaire à jour des extensions et thèmes de chaque site, avec leurs versions.
- Abonnez-vous aux alertes d'une base de vulnérabilités publique ou utilisez un outil qui croise automatiquement vos versions avec ces bases.
- Supprimez les extensions inutilisées : moins de code installé, c'est moins de failles possibles.
- Automatisez les mises à jour de sécurité, avec sauvegarde préalable et retour arrière possible.
- Préférez les extensions activement maintenues, avec des mises à jour régulières et un historique de corrections rapides.
Erreurs fréquentes à éviter
- Attendre « la prochaine maintenance » pour une faille critique déjà exploitée.
- Mettre à jour sans sauvegarde, puis découvrir que le site ne s'affiche plus.
- Considérer l'incident clos après la mise à jour, sans vérifier l'absence d'intrusion.
- Garder une extension abandonnée parce qu'elle « fonctionne encore ».
Comment V-Shield vous aide
V-Shield gère les mises à jour du cœur, des extensions et des thèmes avec possibilité de retour arrière : si une mise à jour casse une page, vous revenez à la version précédente. Avant chaque intervention, les sauvegardes stockées hors de votre hébergement et les instantanés vous protègent. Le pare-feu applicatif filtre les tentatives d'injection SQL et XSS pendant la fenêtre d'exposition, et le scan automatique, quotidien ou toutes les 6 heures selon la formule, détecte les portes dérobées et comptes frauduleux si une faille a été exploitée. Le détail des fonctionnalités et la grille des tarifs vous aident à choisir. Pour une vue d'ensemble, consultez notre checklist sécurité WordPress et notre article sur le pare-feu applicatif WAF.
Vous pensez qu'une faille a déjà été exploitée sur votre site ? Parlez à un expert V-Shield pour un diagnostic rapide.
Questions fréquentes
Comment savoir si un plugin WordPress que j'utilise est vulnérable ?
Consultez les bases publiques de vulnérabilités comme WPScan, Wordfence Intelligence ou Patchstack, qui recensent les failles par extension et par version. Comparez avec les versions installées sur votre site. Un outil de surveillance peut faire ce rapprochement automatiquement et vous alerter dès qu'une faille concerne un de vos composants.
Que signifie le score CVSS d'une vulnérabilité ?
Le score CVSS est une note de 0 à 10 qui estime la gravité technique d'une faille. Au-delà de 7, elle est considérée comme élevée, au-delà de 9 comme critique. Ce score ne dit pas tout : une faille moyenne exploitable sans compte peut être plus urgente qu'une faille élevée qui exige un accès administrateur.
Que faire si aucun correctif n'est encore disponible ?
Désactivez l'extension si votre site peut s'en passer temporairement, ou remplacez-la par une alternative maintenue. Si elle est indispensable, limitez l'accès aux fonctions concernées, renforcez le pare-feu applicatif et surveillez attentivement les journaux et l'intégrité des fichiers jusqu'à la publication du correctif.
Une extension désactivée peut-elle encore être exploitée ?
Oui, dans certains cas. Les fichiers d'une extension désactivée restent sur le serveur et certains peuvent être appelés directement par une adresse web. Une extension inutilisée doit donc être supprimée, pas seulement désactivée. C'est l'une des mesures de sécurité les plus simples et les plus efficaces.
Faut-il activer les mises à jour automatiques des plugins WordPress ?
Pour les correctifs de sécurité, c'est généralement préférable : la fenêtre d'exposition se réduit fortement. Le risque est qu'une mise à jour casse une fonctionnalité. La bonne approche consiste à automatiser avec une sauvegarde préalable et une possibilité de retour arrière, et à tester les mises à jour majeures sur une copie.