Extension WordPress signalée vulnérable alors qu’elle est à jour : comment trancher

Extension WordPress signalée vulnérable : d’où vient l’alerte

Le cas revient chaque semaine sur les forums WordPress.org : une extension WordPress signalée vulnérable alors que la dernière version est installée. Le message cite un CVE, parfois trois failles d’un coup, et la mise à jour ne change rien. Avant d’ignorer l’alerte ou de désinstaller l’extension dans l’urgence, il faut comprendre comment elle est produite.

Un contrôle de vulnérabilités ne lit pas le code de votre extension. Il compare deux choses : le nom et la version de ce qui est installé, et une liste publique de failles connues, où chaque faille est rattachée à une extension et à une plage de versions concernées. Quand les deux se recoupent, l’alerte s’affiche.

Le principe est simple et rapide, mais chaque côté de la comparaison peut se tromper. Les causes les plus fréquentes d’une alerte sur une version à jour sont les suivantes.

• La liste est fausse ou en retard : la faille a été corrigée dans la dernière version, mais l’entrée indique encore « toutes les versions » ou une plage trop large. C’est la cause la plus courante des faux positifs.
• Deux extensions portent le même identifiant : une extension ou un thème vendu hors du répertoire WordPress.org peut partager son nom de dossier avec un autre, et hériter de ses failles.
• La version lue n’est pas la bonne : certains produits premium déclarent un numéro dans leur en-tête qui ne correspond pas à celui de leur propre écran de mise à jour.
• Le résultat date d’avant la mise à jour : l’outil n’a pas encore refait sa vérification.
• L’alerte vise le mauvais élément : la faille concerne une bibliothèque embarquée, ou WordPress lui-même après une mise à jour du cœur, et elle est rattachée à une extension.

Faux positif ou faille sans correctif : la différence qui compte

Toutes les alertes sur une version à jour ne sont pas des erreurs. Une faille peut être rendue publique avant que l’auteur ait publié une correction. Dans ce cas, la dernière version est réellement vulnérable, et l’alerte est juste.

Pour trancher, ouvrez la fiche de la faille dans la base qui la publie, à partir de sa référence CVE ou du lien donné par l’alerte. Lisez trois informations.

Si la fiche indique une version corrigée égale ou inférieure à la vôtre, il s’agit d’un faux positif. Si elle n’indique aucun correctif, la faille est ouverte : il faut agir en attendant l’auteur. Si la fiche reste floue, le journal des modifications de l’extension et son forum de support tranchent souvent la question en une ligne.

• Les versions concernées : « jusqu’à 7.5.1 inclus » et « avant 7.5.1 » ne disent pas la même chose.
• La version corrigée, ou la mention qu’aucun correctif n’existe encore.
• La date de publication de la faille, à comparer avec la date de votre version.

Une alerte sur une version à jour veut dire « vérifiez », ni « paniquez », ni « ignorez ».

Ce que vérifie le module Sécurité de nexya

nexya rassemble les tâches courantes d’un site WordPress dans un seul panneau d’administration. Chaque tâche est un module que l’on allume ou que l’on éteint depuis le hub. Un module éteint n’enregistre rien : aucun de ses crochets ne tourne sur le site.

Le module Sécurité vérifie les extensions installées contre la liste des failles connues. Il pose aussi les en-têtes de sécurité, une politique de contenu, et une limite aux connexions échouées.

Ce contrôle repose, comme les autres, sur une liste de failles connues. Il peut donc lui aussi relayer une entrée mal renseignée. La méthode de la section précédente s’applique telle quelle : la fiche de la faille et le numéro de version installé font foi.

Tout ce qui suit est gratuit, sur autant de sites que vous voulez, sauf ce qui est marqué Pro. La version gratuite ne contient pas le code des fonctions Pro ; nexya Pro est livré par Freemius après l’achat et reprend les mêmes réglages.

• Gratuit : la vérification des extensions installées contre la liste des failles connues, les en-têtes de sécurité, la politique de contenu, la limite aux connexions échouées.
• nexya Pro : un passage quotidien sur les vulnérabilités, et une empreinte des fichiers avec retour arrière.
• nexya Pro : une connexion en deux étapes pour les rôles que vous choisissez.

Retrouver ce qui a changé, et quand

Une alerte qui apparaît juste après une mise à jour pose deux questions : la version a-t-elle vraiment changé, et qui a fait le changement ? Commencez par le numéro affiché dans la liste des extensions de WordPress, et comparez-le à celui de la fiche de la faille.

Le module Journal d’activité garde qui a changé quoi sur le site, avec l’avant et l’après. Sur un site géré à plusieurs, c’est le moyen le plus court de savoir ce qui a été touché, par qui, et à quel moment, sans avoir à interroger toute l’équipe.

Si les numéros concordent avec une version corrigée et que l’alerte persiste, laissez l’outil refaire sa vérification. Un résultat ancien, calculé avant la mise à jour, explique une partie des messages qui semblent absurdes.

Vérifier une alerte de vulnérabilité, pas à pas

1. 1

   Allumer le module Sécurité

   Dans le hub nexya, activez le module Sécurité. Il vérifie les extensions installées contre la liste des failles connues. Éteint, il n’enregistre rien sur le site.

   
2. 2

   Comparer votre version à la fiche de la faille

   Relevez le numéro de version dans la liste des extensions, ouvrez la fiche de la faille et lisez les versions concernées et la version corrigée. Le journal d’activité vous dit qui a changé quoi, et quand.

   
3. 3

   Mettre à jour à l’abri, ou signaler le faux positif

   Si un correctif existe, mettez à jour derrière la page d’attente du module Maintenance : la version précédente est gardée et se remet en un clic. Si la fiche est fausse, signalez-le à la base de failles et à l’auteur.

   

Corriger sans casser le site

La suite dépend de ce que dit la fiche. Dans les trois cas, l’objectif est le même : ne pas laisser une vraie faille ouverte, et ne pas abîmer un site qui fonctionne pour une alerte infondée.

Une mise à jour d’extension reste une intervention sur un site en production. Le module Maintenance garde la version précédente de chaque extension et de chaque thème juste avant sa mise à jour, et la remet en place en un clic. Il propose aussi une page d’attente pour fermer le site le temps de l’intervention.

Dans nexya Pro, une mise à jour qui casse le site est annulée d’elle-même, et l’administrateur reçoit un e-mail.

• Faille avec correctif : mettez à jour, vérifiez le site, puis laissez le contrôle se refaire.
• Faille sans correctif : désactivez l’extension si vous pouvez vous en passer, ou cherchez une remplacante, et suivez le forum de l’auteur.
• Faux positif : signalez-le à la base de failles et à l’auteur, avec votre numéro de version et la référence de la correction, puis notez-le pour l’équipe.

Ce que nexya ne fait pas

Le module Sécurité ne corrige pas une liste de failles tenue par d’autres, et il ne peut pas garantir qu’une entrée publique est exacte. Il signale ; la lecture de la fiche reste votre travail.

nexya n’a pas de scan anti-malware lourd et ne nettoie pas un site piraté. Il vérifie les extensions installées contre les failles connues et, en Pro, contrôle l’empreinte des fichiers. Les réseaux multisite ne sont pas pris en charge : sur un réseau, le plugin reste éteint et l’indique.