Auditer WordPress ? Commencez par vos plugins

Résumé

La plupart des audits de sécurité WordPress sont à l'envers : ils mettent l'accent sur les mises à jour du noyau et les rapports de scanneurs, alors que les vulnérabilités qui mordent réellement se trouvent dans les plugins. Un livre blanc de SANS a constaté que plus de 96 % des vulnérabilités de l'écosystème proviennent de plugins tiers, et environ 43 % ne nécessitent aucune authentification. Cet article présente un audit axé sur les plugins pour une petite équipe marketing interne, en s'appuyant sur l'histoire d'un site qui a été piraté parce que tout le monde scannait la mauvaise couche. Vous apprendrez à inventorier et classer chaque plugin, tester les surfaces d'attaque non authentifiées, examiner manuellement les utilisateurs et les journaux, et traduire les résultats dans un langage de risque qu'un patron non technique comprend. Le résultat est un rituel de triage trimestriel plutôt qu'un exercice de cases à cocher.

La plupart des audits de sécurité WordPress sont du théâtre. Vous passez un après-midi à mettre à jour le noyau, à changer le mot de passe administrateur et à exécuter un scanneur de plugins qui affiche fièrement « Aucun problème critique ». Pendant ce temps, le plugin qui acceptait les téléversements de fichiers et qui a été mis à jour pour la dernière fois il y a trois ans reste tranquillement dans votre répertoire de téléversements, attendant quelqu'un qui n'est pas sur la liste des invités.

Les chiffres le confirment. Un livre blanc de SANS sur l'analyse des plugins WordPress a révélé que plus de 96 % des vulnérabilités de l'écosystème WordPress proviennent de plugins tiers, les thèmes représentant 4 % et le noyau moins de 1 %. Environ 43 % de ces failles peuvent être exploitées sans aucune authentification. Ainsi, lorsque votre audit consacre la majeure partie de son énergie au noyau, vous examinez les arbres pendant qu'un incendie de forêt se déclare dans le répertoire de plugins voisin.

Ce n'est pas un appel à paniquer à propos du noyau. Les vulnérabilités du noyau comme les failles RCE wp2shell qui ont récemment fait l'objet d'exploits publics devraient être corrigées le jour de leur annonce. Mais elles sont assez rares pour ne pas mériter la majeure partie de vos heures d'audit. L'essentiel appartient aux plugins, et c'est là que le véritable processus commence.

Imaginez le scénario avant : un dimanche matin, votre site redirige vers une page de casino, et votre patron vous écrit : « Je pensais que nous étions en sécurité ». Vous aviez bien une sécurité — vous aviez un audit par cases à cocher. Le scénario après est un système de triage qui traite les plugins comme la surface d'attaque qu'ils sont réellement, les teste de l'extérieur et vérifie les choses que les scanneurs ne peuvent pas voir.

Vous faites partie d'une petite équipe marketing avec un site WordPress qui fonctionne depuis 2017. Il possède un plugin personnalisé d'inscription à des événements qu'un freelance a créé en 2019, un plugin de formulaire de contact avec un champ de téléversement de fichier, et un plugin de diaporama qui a été vendu et n'a plus de page de mises à jour publique. Ce n'est pas une pile inhabituelle. C'est là que votre audit commence.

---

L'inventaire des plugins est votre politique de sécurité

Inventoriez chaque plugin et thème. Notez la version, la date de dernière mise à jour, si le fournisseur est toujours en activité, et si quelqu'un l'utilise réellement. Puis classez chacun dans une catégorie : maintenu et utilisé, maintenu et non utilisé, abandonné mais utilisé, abandonné et non utilisé. Supprimez immédiatement ceux qui ne sont pas utilisés. Ignorez l'argument « ce n'est que 50 $/mois » — un plugin non utilisé est un passif, pas une fonctionnalité. Pour ceux abandonnés mais utilisés, décidez : remplacez-le, ou acceptez le risque et notez-le dans un registre des risques que votre patron a vu.

Le plugin d'inscription à des événements entre dans la catégorie abandonné mais utilisé. Il gère les paiements et envoie des e-mails de confirmation, et le remplacer représente un projet, alors vous le gardez pour l'instant. Mais vous écrivez une note indiquant : « c'est la source la plus probable d'une future violation », et vous l'ajoutez en haut de la liste de tests.

Surface d'attaque	Part des vulnérabilités WordPress connues	Priorité d'audit
Plugins tiers	Plus de 96 %	Maximale — inventorier, scanner, tester, remplacer
Thèmes	Environ 4 %	Moyenne — uniquement si personnalisés ou obsolètes
Noyau WordPress	Moins de 1 %	Faible — maintenir les corrections, passer à autre chose

Quand SecurityWeek a recensé plus de 8 000 nouvelles vulnérabilités WordPress en 2024, la grande majorité était de ce type : des problèmes de plugins, pas des correctifs du noyau. Un scanneur vous informera de celles qui ont été divulguées et ont reçu un CVE. Il ne vous dira rien sur le code personnalisé du freelance sans CVE, parce que personne ne l'a jamais examiné attentivement. Cet examen manuel est votre travail. Pour une procédure plus détaillée des vérifications spécifiques aux plugins, consultez ce guide sur l'audit de vos plugins WordPress pour détecter les vulnérabilités.

---

Testez-le comme un étranger : les 43 % qui n'ont pas besoin de mot de passe

Votre scanneur vous a déjà dit que rien ne va pas. Maintenant, faites ce qu'il ne peut pas faire : sonder le site de l'extérieur, sans connexion. Commencez par chaque champ de téléversement de fichier, chaque formulaire qui traite un POST, chaque point de terminaison admin-ajax. Le téléversement vérifie-t-il réellement le contenu du fichier, ou seulement l'extension ? Où atterrissent les fichiers téléversés, et le serveur web peut-il exécuter du PHP dans ce répertoire ? Les 43 % de failles de plugins qui ne nécessitent pas d'authentification se trouvent généralement exactement dans ces endroits : XSS stocké non authentifié, téléversement de fichier arbitraire et injection d'objets PHP.

Le plugin de formulaire de contact permet aux visiteurs de joindre un CV. Il renomme le fichier en utilisant le nom de fichier d'origine du visiteur, donc vous téléversez « resume.php » et il l'enregistre dans un dossier /uploads/contact/ qui est inscriptible par conception. Si le serveur permet également d'exécuter du PHP dans ce répertoire, l'attaquant vient d'obtenir un webshell. Fastly a documenté l'exploitation active de XSS stocké non authentifié dans des plugins WordPress — ce n'est pas un risque de niche pour des diapositives. Votre test est simple : créez un fichier avec un contenu connu, téléversez-le, et voyez s'il revient avec son nom et son type d'origine. Ensuite, essayez de téléverser un fichier .php. S'il revient en .php, vous venez de trouver une faille exploitable.

C'est aussi là que l'argument « mais notre plugin de sécurité a un WAF » s'effondre. Un WAF peut bloquer une charge utile connue, mais les règles de normalisation de chemin sur lesquelles il s'appuie divergent souvent de ce que le serveur fait réellement. Le Guide de test de sécurité web de l'OWASP est une meilleure référence que n'importe quel tableau de bord : il décrit comment tester les failles de téléversement de fichiers et le XSS stocké de manière méthodique. Et si vous découvrez que le plugin est abandonné, il est temps d'appliquer le protocole de nettoyage : le danger caché des plugins WordPress abandonnés explique pourquoi laisser une extension morte en place est pire que de la supprimer et d'ajuster votre flux de travail.

---

Ce que le scanneur ne peut pas voir : utilisateurs, journaux et ancien code

Les tests dynamiques détectent ce qui est exposé à l'instant. L'examen manuel détecte ce qui est déjà à l'intérieur. Commencez par les comptes utilisateurs : ouvrez la liste d'administration et cherchez des comptes que vous n'avez pas créés. Un administrateur nommé « support » avec une adresse e-mail gratuite et aucun humain derrière est une porte dérobée, pas un collègue. Vérifiez les horodatages des fichiers dans wp-content/uploads pour tout élément récemment modifié qui n'est pas votre contenu. Consultez le journal d'accès du serveur pour détecter les requêtes qui ressemblent à une commande curl d'un bot plutôt qu'au navigateur d'une personne.

Le plugin d'événement a un téléversement « photo de l'intervenant » qui enregistre dans uploads/event-headshots/. Pendant le test, vous trouvez un fichier qui n'est pas l'un des vôtres — un petit fichier PHP avec un nom d'apparence aléatoire. C'est votre webshell. Il est arrivé là par la même faille de téléversement que vous avez testée il y a deux semaines, et maintenant, un scanneur ne le « verrait » toujours pas parce que ce n'est pas une vulnérabilité de plugin ; c'est la preuve d'une vulnérabilité. L'examen manuel le trouve, le supprime, et vérifie le journal pour trouver l'adresse IP qui l'y a placé. Invicti a noté que l'injection d'objets PHP dans les plugins est en hausse, et elle est presque invisible pour les scans en boîte noire car l'objet malveillant ne se matérialise qu'au moment de l'exécution. La seule façon de la repérer est de lire le code à la recherche de modèles dangereux comme l'appel de unserialize() sur une entrée fournie par l'utilisateur. Lire quelques centaines de lignes du plugin personnalisé coûte moins cher que de payer un contrat de réponse à incident.

C'est aussi là que le conseil standard de « installez simplement plus de plugins de sécurité » atteint sa limite. Empiler trois plugins de sécurité vous donne des règles WAF qui se chevauchent et se bloquent mutuellement, un torrent d'e-mails de journaux en double, et l'erreur occasionnelle « vous êtes banni » sur votre propre connexion d'admin. Un seul plugin de sécurité actif, bien configuré, suffit. Lisez pourquoi trop de plugins de sécurité se retournent contre vous avant d'ajouter quoi que ce soit à la pile.

---

Dire la vérité à votre patron sans déclencher de panique

Votre patron ne se soucie pas des scores CVSS ni de l'injection d'objets PHP. Il se soucie de la panne du site, de la boutique qui ne prend plus de commandes et du budget informatique. La traduction est simple : « Ce plugin présente une faille connue d'exécution de code à distance non authentifiée. Un étranger peut supprimer le contenu de notre site ou installer une porte dérobée. Nous devons le remplacer ce trimestre. » Ensuite, montrez la liste des priorités : remplacer le plugin d'événement, désactiver le téléversement de fichiers du formulaire de contact jusqu'à ce qu'il valide correctement les types de fichiers, faire pivoter toutes les informations d'identification administrateur, et planifier la prochaine revue trimestrielle.

Vous avez aussi un avantage linguistique : la CISA tient un catalogue des vulnérabilités connues et exploitées, qui vous indique exactement quelles failles publiées sont activement utilisées dans la nature. Si l'un de vos plugins y figure, l'argument n'est plus théorique — un exploit connu existe, et le temps est compté. Sinon, utilisez-le quand même comme étalon de ce que signifie « urgent ». Le suivi de la CISA facilite la conviction d'un patron non technique que ce n'est pas un e-mail de phishing ; c'est une base de données publique de ce que font les attaquants en ce moment. À la fin du trimestre, vous aurez un processus de remédiation, et non un exercice ponctuel de cases à cocher. Un processus pour transformer les vulnérabilités en cycle de correctifs maintient l'habitude en vie.

---

L'avant était un site cassé, un e-mail frénétique et un rapport de scanneur vierge qui ne signalait rien d'anormal. L'après est un rituel trimestriel : inventorier, classer, tester de l'extérieur, examiner les utilisateurs et les journaux, et consigner les décisions prises et les risques acceptés. Le scanneur devient une carte indiquant où chercher, et non un certificat de bonne santé. Les plugins deviennent une liste que vous connaissez par nom. Et la prochaine fois que votre patron posera des questions sur l'audit, vous aurez une réponse qui n'implique pas de croiser les doigts.