Vous avez mis à jour vos extensions, configuré HTTPS et paramétré un pare-feu. Votre site semble sécurisé. Mais comment savoir si l’une des extensions installées ne présente pas une vulnérabilité actuellement exploitée?

La vérification manuelle croisée avec les bases de données de vulnérabilités prend des heures. WPScan le fait en une trentaine de secondes: un scanner de sécurité WordPress open source doté d’une interface en ligne de commande qui, d’après les statistiques de sa propre base de données, suit plus de 73 000 vulnérabilités dans le cœur, les extensions et les thèmes. Au programme: installation, jeton API, scan basique et avancé, attaque par force brute des mots de passe.

💡 Aperçu rapide:

• Installez WPScan via le gem Ruby, Docker ou Homebrew et mettez à jour la base de métadonnées avec wpscan --update

• Enregistrez un jeton API gratuit sur wpscan.com: 25 requêtes par jour, sans jeton le scanner n’affichera pas les données de vulnérabilité

• Lancez un scan basique: wpscan --url https://your-site.com --api-token YOUR_TOKEN

• Vérifiez les extensions et thèmes vulnérables avec les options -e vp et -e vt, énumérez les utilisateurs avec -e u

• Pour l’attaque par force brute des mots de passe, préparez un fichier de liste de mots et passez-le avec l’option --passwords

Qu’est-ce que WPScan

WPScan, un scanner de sécurité WordPress gratuit pour un usage non commercial, est écrit en Ruby. La première version est sortie en juin 2011 et, depuis, l’outil est devenu la référence de facto pour le pentesting des sites WordPress.

Le scanner croise la version installée de WordPress, les extensions actives et les thèmes avec la base de données de vulnérabilités WordPress disponible sur wpscan.com, maintenue par une équipe de spécialistes en sécurité. Selon les statistiques de la base, elle documente plus de 73 000 vulnérabilités dans le cœur, les extensions et les thèmes. Chaque entrée est vérifiée manuellement par une équipe dédiée d’experts WordPress. Depuis 2023, WPScan est une autorité de numérotation CVE et attribue directement des numéros CVE aux vulnérabilités de l’écosystème WordPress.

Au-delà des vulnérabilités, WPScan peut énumérer les identifiants utilisateur via l’API REST et les flux auteur, attaquer les mots de passe par force brute à partir d’un dictionnaire, trouver des sauvegardes exposées de wp-config.php, des dumps de base de données et des journaux d’erreurs ouverts.

Une nuance de licence importante: l’utilisation gratuite du scanner en ligne de commande est autorisée uniquement à des fins non commerciales. Les agences qui scannent les sites de leurs clients ont besoin d’un abonnement payant. Les conditions sont décrites sur le site officiel de WPScan.

Installation et mises à jour

WPScan est disponible de trois manières. Choisissez celle qui correspond à votre flux de travail.

Gem Ruby, option universelle pour Linux, macOS et Windows avec Ruby installé:

1
gem install wpscan

Docker, environnement isolé sans dépendances:

1
docker pull wpscanteam/wpscan

Exemple d’exécution Docker:

1
docker run -it --rm wpscanteam/wpscan --url https://example.com -e u

Homebrew, pour macOS:

1
brew install wpscanteam/tap/wpscan

Après l’installation, commencez par mettre à jour la base de métadonnées locale. Elle contient les informations sur les dernières versions des extensions et des thèmes, sans elle le scanner ne peut pas déterminer si la version installée est obsolète. Les informations de vulnérabilité sont demandées séparément via l’API en temps réel.

1
wpscan --update

La mise à jour prend quelques secondes. La sortie affiche la version de WPScan et confirme que la base de données est à jour. Répétez wpscan --update avant chaque audit: les développeurs publient des mises à jour des métadonnées plusieurs fois par semaine.

Jeton API: la clé d'accès aux données de vulnérabilité

L'erreur de débutant la plus courante: lancer wpscan --url site.com sans jeton et se demander pourquoi le scanner ne signale aucune vulnérabilité. Sans jeton, WPScan fonctionne en mode «métadonnées uniquement». Il vous indiquera qu'un plugin est obsolète, mais ne précisera pas quels CVE lui sont associés.

Inscrivez-vous sur wpscan.com, c'est gratuit et cela prend une minute. L'offre gratuite donne droit à 25 requêtes API par jour. Un scan consomme 1 requête pour la version de WordPress, 1 requête pour chaque plugin installé et 1 requête pour chaque thème. Un site WordPress typique compte plus d'une dizaine de plugins installés, la limite gratuite est donc suffisante pour un scan complet par jour.

Le jeton est transmis via l'option --api-token à chaque exécution:

1
wpscan --url https://example.com --api-token YOUR_TOKEN

Pour éviter de saisir le jeton à chaque commande, enregistrez-le dans le fichier de configuration ~/.wpscan/scan.yml:

1
api_token: YOUR_TOKEN

Après cela, WPScan récupérera le jeton automatiquement.

Scan de base d'un site

Commande d'audit minimale:

1
wpscan --url https://example.com --api-token YOUR_TOKEN

Le scanner déterminera la version de WordPress, le thème actif, détectera les numéros de version exposés et vérifiera les problèmes de configuration de base: accessibilité de wp-cron et readme.html, répertoire des uploads, possibilité d'enregistrement des utilisateurs.

La sortie est structurée avec des marqueurs de couleur: vert pour les messages informatifs, jaune pour les avertissements, rouge pour les vulnérabilités trouvées. Chaque vulnérabilité est accompagnée d'un lien vers la fiche de la base de données WPScan avec une description du vecteur d'attaque, des versions affectées et des recommandations de remédiation.

Un scan de base prend généralement moins d'une minute. La durée exacte dépend de la taille du site et de la vitesse de l'hébergement.

Trouver les plugins vulnérables

Les plugins, principal vecteur d'attaque sur WordPress. Selon les statistiques de WPScan, plus de 90% des vulnérabilités connues se situent dans les plugins. La commande de vérification:

1
wpscan --url https://example.com -e vp --api-token YOUR_TOKEN

L'option -e vp (énumérer les plugins vulnérables) liste uniquement les plugins présentant des vulnérabilités connues. C'est le mode le plus rapide et le plus pratique: il croise les plugins installés avec la base de données et ne signale que ceux pour lesquels des problèmes sont documentés.

Par défaut, WPScan utilise le mode de détection passif, en analysant le HTML de la page sans requêtes supplémentaires. Pour obtenir une couverture maximale au prix d'une charge serveur additionnelle, passez en mode mixte:

1
wpscan --url https://example.com -e vp --plugins-detection mixed --api-token YOUR_TOKEN

Le mode mixed applique d'abord l'analyse passive, puis vérifie de manière agressive les chemins de plugins connus pour détecter les installations cachées et inactives.

Si le scanner a trouvé un plugin vulnérable, mettez-le à jour vers la dernière version. Le développeur a presque certainement publié un correctif. S'il n'y a pas de mise à jour et que le plugin est abandonné, supprimez-le et trouvez une alternative. Laisser un plugin avec une vulnérabilité connue sur un site en production est inacceptable.

Trouver les thèmes vulnérables

Les thèmes sont vérifiés de manière similaire aux plugins:

1
wpscan --url https://example.com -e vt --api-token YOUR_TOKEN

L’option -e vt (vulnerable themes) vérifie le thème actif et tous les thèmes installés à la recherche de vulnérabilités connues. Les thèmes sont moins souvent attaqués que les extensions, mais des vulnérabilités existent, en particulier dans les thèmes qui intègrent des constructeurs de pages et des sliders.

Le mode de détection des thèmes par défaut est agressif, car l’analyse passive passe souvent à côté des thèmes inactifs. Si le serveur est peu puissant et que la charge est critique, limitez-vous au mode passif:

1
wpscan --url https://example.com -e vt --themes-detection passive --api-token YOUR_TOKEN

Lorsqu’un thème vulnérable est trouvé, appliquez le même principe: mettez-le à jour ou supprimez-le. Les thèmes enfants héritent des vulnérabilités du thème parent, vérifiez les deux.

Énumération des utilisateurs

Un attaquant qui connaît les identifiants de connexion WordPress n’a plus qu’à deviner les mots de passe. WPScan indique quels identifiants sont visibles depuis l’extérieur:

1
wpscan --url https://example.com -e u

Le scanner parcourt les ID utilisateur et extrait les identifiants depuis l’API REST, les flux auteur (/author/name/) et d’autres points d’accès publics. Le résultat ressemble à ceci:

1
[i] User(s) Identified:
2
[+] admin
3
[+] editor
4
[+] serg

Dans l’idéal, vous ne devriez voir aucun identifiant. Si WPScan a trouvé des utilisateurs, prenez des mesures:

• Définissez un nom public différent de l’identifiant dans les paramètres du profil.
• Désactivez l’API REST pour les visiteurs non authentifiés via une extension ou le .htaccess.
• Un pare-feu au niveau DNS, comme Sucuri ou Cloudflare, bloquera le scanner avant qu’il n’arrive: vous verrez une erreur de délai d’attente au lieu d’une liste d’utilisateurs.

Les versions actuelles de WordPress limitent l’énumération via l’API REST, mais les thèmes et les extensions peuvent ouvrir des contournements. Se reposer uniquement sur le cœur de WordPress est insuffisant.

Attaque par force brute des mots de passe

WPScan prend en charge les attaques par dictionnaire. Le scanner tente de s’authentifier pour chaque utilisateur trouvé avec chaque mot de passe d’un fichier liste. L’opération est gourmande en ressources, mais le résultat en vaut la peine: vous saurez si un administrateur utilise qwerty123.

Préparez un fichier texte avec un mot de passe par ligne, puis lancez:

1
wpscan --url https://example.com -e u --passwords /path/to/passwords.txt

Des listes de mots prêtes à l’emploi sont disponibles dans Kali Linux (/usr/share/wordlists/) et dans des sources ouvertes comme le dépôt SecLists sur GitHub. Pour un contrôle de base, un fichier de 500 à 1000 mots de passe parmi les plus courants est suffisant.

Le paramètre --threads N contrôle le nombre de tentatives simultanées. La valeur par défaut est 5. Passer à 20 ou 30 accélère la force brute, mais génère une charge serveur perceptible et peut déclencher les protections de l’hébergeur.

Avant de lancer une attaque par force brute, sauvegardez le site et prévenez l’hébergeur: certains bloquent les adresses IP en cas de multiples échecs d’authentification.

Capacités complémentaires

WPScan ne se limite pas à l’audit basique des extensions et des utilisateurs. Voici quelques scénarios utiles.

Trouver toutes les extensions, pas seulement les vulnérables:

1
wpscan --url https://example.com -e ap --api-token YOUR_TOKEN

L’option -e ap (all plugins) énumère toutes les extensions de la base WPScan. L’opération prend un temps considérable. À réserver aux audits complets, pas aux vérifications de routine.

Détecter les sauvegardes et les exports de base de données:

1
wpscan --url https://example.com -e cb,dbe

Les options cb (config backups) et dbe (database exports) recherchent les sauvegardes de wp-config.php et les exports SQL accessibles publiquement, oubliés par des extensions de sauvegarde. Un tel fichier en accès libre est extrêmement dangereux: un attaquant obtient les identifiants de la base de données.

Scan furtif:

1
wpscan --url https://example.com --stealthy --api-token YOUR_TOKEN

L’option --stealthy ajoute des délais aléatoires entre les requêtes, ce qui fait passer l’activité du scanner pour celle d’un visiteur normal. Utile si le serveur bloque de manière agressive les comportements suspects.

Énumération des fichiers média:

1
wpscan --url https://example.com -e m1-100

Vérifie les identifiants de fichiers média dans la plage spécifiée. Aide à découvrir des documents confidentiels accessibles par lien direct et des sauvegardes téléversées en dehors de la médiathèque.

Tutoriel vidéo complet sur WPScan, de l’installation aux scénarios avancés:

⁉️🤔 Questions fréquentes

WPScan est-il nécessaire si Jetpack Protect ou Wordfence est déjà installé?

Oui, il est nécessaire. Les extensions de sécurité fonctionnent de l’intérieur de WordPress et bloquent les attaques en temps réel. WPScan examine le site de l’extérieur, exactement comme un attaquant. Il trouve des problèmes que l’extension ne voit pas: sauvegardes exposées, énumération d’utilisateurs via des vecteurs non standards, vulnérabilités dans des extensions inactives mais non supprimées. Les deux approches combinées offrent une véritable défense en profondeur.

WPScan est-il sans danger pour mon site? Ne risque-t-il pas de faire planter le serveur?

Le scanner envoie des requêtes HTTP standard, identiques à celles d’un visiteur normal. En mode passif, il analyse uniquement le HTML sans charge supplémentaire. Le mode agressif avec énumération complète des extensions (-e ap) génère des centaines de requêtes et peut ralentir un hébergement peu performant. Pour les vérifications régulières, utilisez -e vp,vt,u, cela représente quelques dizaines de requêtes, sans danger pour tout serveur.

Peut-on automatiser le scan?

Oui. Pour les développeurs, une tâche cron qui exécute un conteneur Docker une fois par semaine et envoie un rapport par email fonctionne très bien. Pour tous les autres, le service WPScan.com scanne automatiquement les sites de façon planifiée et envoie des notifications sur les nouvelles vulnérabilités. Fréquence optimale: scan complet une fois par semaine, vérification des composants prioritaires quotidiennement. Pour les audits manuels, l’interface en ligne de commande gratuite est suffisante; pour une surveillance continue, envisagez une solution automatisée.

Que faire si WPScan trouve une vulnérabilité et qu’il n’y a pas de mise à jour?

L’extension est abandonnée par son développeur. Algorithme: (1) vérifiez si la vulnérabilité est activement exploitée, la fiche de la base WPScan contient cette information; (2) s’il n’y a pas d’attaques et que l’extension est critique pour l’activité, restreignez temporairement son accès via .htaccess et planifiez son remplacement; (3) si des attaques sont enregistrées, supprimez l’extension immédiatement. Aucun compromis n’est possible ici entre fonctionnalité et sécurité.

En quoi WPScan diffère-t-il des autres scanners WordPress?

WPScan est le seul scanner doté d’une base de données de recherche de vulnérabilités dédiée, qui existe depuis plus de dix ans. Les alternatives comme WPSeku énumèrent les extensions à partir d’une liste statique, sans fiches CVE détaillées. WPScan est soutenu par Automattic via un partenariat avec Jetpack, ce qui garantit le développement du projet sur le long terme.

Que choisir: CLI, Docker ou SaaS

Le choix dépend de vos besoins. Résumé rapide:

• Si vous avez un seul site et avez besoin d’un contrôle ponctuel, utilisez Docker: une commande, zéro dépendance.
• Si vous avez plus de dix sites et avez besoin de rapports réguliers, la gem Ruby dans une tâche cron s’en chargera.
• Si vous êtes une agence avec une centaine de sites clients, un abonnement WPScan SaaS vous enlèvera le souci de la surveillance.

N’oubliez pas le jeton API: sans lui, vous ne voyez que la moitié du tableau. Commencez par les trois commandes du bloc «Aperçu rapide» ci-dessus. Trente secondes, et vous savez exactement si le site présente des vulnérabilités ouvertes. Quel outil de sécurité vous a aidé en pratique? Écrivez-le dans les commentaires.