Sécurité
Scanner de mises à jour WordPress
Détecte le cœur WordPress, les plugins et les thèmes installés sur un site à partir de son code source public, et les compare à la dernière version stable pour repérer ce qui a besoin d'une mise à jour.
L’outil ne lit que les informations publiquement exposées par le site (fichiers, en-têtes, numéros de version affichés dans le code source). Aucune tentative d’exploitation, aucun accès à des données privées.
Comment utiliser cet outil
- 1Entrez l'URL du site WordPress à analyser
- 2L'outil lit les fichiers et numéros de version exposés publiquement dans le code source
- 3Chaque plugin, thème et le cœur WordPress sont comparés à la dernière version stable connue
- 4Les éléments obsolètes ou dont la version n'est pas exposée publiquement sont signalés
Ce que votre code source révèle de vos mises à jour WordPress
Un site WordPress laisse voir dans son HTML une bonne partie de sa mécanique : les dossiers de ses extensions, son thème, souvent leurs numéros de version. Ce scanner lit ces traces publiques, les compare aux dernières versions publiées sur wordpress.org et, quand la vérification est active, interroge une base de vulnérabilités. Il dit ce qui semble en retard, pas si le site est sûr.
D'où viennent les versions affichées
L'outil charge une seule page, celle dont vous donnez l'adresse, plus le flux /feed/ si le cœur n'affiche pas sa version, sans exécuter de JavaScript. Il y relève les chemins en wp-content/plugins/ et wp-content/themes/ pour identifier les extensions et le thème, et lit le paramètre ?ver= ajouté aux fichiers CSS et JS. Seule une valeur avec un point, comme 6.5.2, est retenue comme version : un entier ou une date à huit chiffres sert au cache et serait trompeur. La version du cœur vient de la balise meta generator, ou à défaut du flux /feed/. Chaque élément est ensuite comparé à la dernière version publiée sur wordpress.org, dans la limite de 25 extensions et 25 thèmes. Une précision qui évite des fausses alertes : quand un développeur n'indique pas de version à son fichier, WordPress y ajoute la sienne. Une extension qui affiche exactement la version du cœur mérite donc une vérification dans l'administration avant toute conclusion.
Lire la suiteRéduire
Quatre statuts, et des angles morts assumés
Chaque ligne reçoit un statut. Rouge avec un bouclier, une faille connue touche encore la version détectée. Rouge, une version plus récente existe. Vert, la version détectée est la dernière publiée. Gris, la comparaison est impossible : version masquée, ou extension absente du répertoire wordpress.org, ce qui est le cas de la plupart des extensions premium. Les vulnérabilités viennent de la base WPScan. Par quota, au plus dix éléments à version connue sont vérifiés par analyse, cœur compris, et le compteur du haut compte les éléments touchés, pas le nombre de failles. Si la vérification est inactive, un message le signale. Si le quota du jour est épuisé, les éléments restent sans information de faille, sans alerte particulière. L'outil ne voit pas ce que la page ne charge pas : une extension sans fichier public sur la page d'accueil, comme un outil de sauvegarde ou de sécurité, n'apparaît pas. Il ne teste ni les fichiers exposés, ni la configuration du serveur, ni les comptes d'administration. Analyser aussi une page de formulaire ou de boutique fait souvent apparaître d'autres extensions.
Par quoi commencer après le scan
Je traite d'abord les lignes avec bouclier rouge : une faille connue dans une version installée est la situation que les robots d'attaque cherchent en masse. Ensuite le cœur s'il est en retard, puis les extensions dont le retard est le plus important. Une mise à jour se prépare : sauvegarde complète, test sur une copie du site si possible, puis mise à jour une extension à la fois pour savoir laquelle casse quoi. Une extension en retard depuis longtemps mérite aussi un coup d'œil à sa fiche sur wordpress.org : si son éditeur ne la met plus à jour depuis des années, la question devient son remplacement. Une ligne grise ne veut pas dire que tout va bien. Vérifiez la version dans l'administration et comparez-la au site de l'éditeur. Et un tableau entièrement vert reste un constat d'obsolescence, pas un audit de sécurité. Si un statut vous semble faux ou difficile à interpréter, envoyez-moi l'adresse analysée et l'élément en question via le formulaire « Un résultat difficile à interpréter ? » juste sous l'outil.
Questions fréquentes
L'outil exploite-t-il des failles ou scanne-t-il des données privées ?
Non. Il lit uniquement les informations publiquement exposées par le site (chemins de fichiers, numéros de version dans le code source, fichiers de flux RSS), la même chose que verrait n'importe quel visiteur ou moteur de recherche. Aucune tentative d'exploitation, aucun accès à des données privées.
Pourquoi certaines versions ne sont-elles pas détectées ?
De plus en plus de sites masquent les numéros de version par mesure de sécurité (suppression du paramètre `?ver=`, retrait de la balise generator). L'outil signale alors le plugin ou thème comme détecté, avec version non exposée, plutôt que d'inventer une information.
L'outil vérifie-t-il les vulnérabilités connues (CVE) ?
Oui, via la base de vulnérabilités WPScan, pour les éléments dont la version installée est détectable. Seules les failles qui affectent encore cette version précise sont affichées (non corrigées, ou corrigées dans une version plus récente). Par précaution de quota, une analyse vérifie au maximum les 10 premiers éléments à version connue.
Un résultat 'à jour' garantit-il l'absence de faille ?
Non. Une version peut être la plus récente disponible et contenir malgré tout une vulnérabilité non corrigée. Cet outil mesure l'obsolescence, pas l'absence totale de risque.
Une extension affiche la même version que WordPress, est-ce une erreur ?
Souvent, oui. Quand une extension charge un fichier sans préciser sa propre version, WordPress ajoute automatiquement son numéro de version au paramètre ?ver=, et l'outil le lit comme celui de l'extension. Vérifiez la version réelle dans la liste des extensions de l'administration avant de conclure à un retard ou à une faille.
Pourquoi une de mes extensions n'apparaît-elle pas dans le résultat ?
L'outil ne voit que les extensions qui chargent un fichier public sur la page analysée. Une extension d'administration, de sauvegarde ou active seulement sur certaines pages reste invisible depuis l'accueil. Relancez l'analyse sur une page où elle intervient, ou faites l'inventaire complet depuis le tableau de bord.
Tester un autre outil
À lire aussi
PDF et accessibilité : pourquoi vos documents administratifs sont hors des clous
Un PDF publié sur un site public est soumis aux mêmes obligations RGAA qu'une page web. Les erreurs les plus fréquentes et comment les corriger.
Comment tester l'accessibilité de son site sans expert RGAA en interne
Un premier diagnostic d'accessibilité est possible en interne avec des outils gratuits et une méthode simple, avant de savoir ce qui nécessite un vrai audit RGAA.
Obligation RGAA pour les entreprises privées en 2025-2026 : qui est concerné, quels délais, quels risques
La loi ELAN et ses décrets étendent les obligations RGAA au-delà du secteur public. Qui est vraiment concerné, quels délais, quelles sanctions, et par où commencer sans bloquer les projets en cours.