WPScan 2026 : Guide Complet pour Auditer et Sécuriser un Site WordPress

WordPress propulse 43% des sites web mondiaux en 2026, ce qui en fait la cible numéro un des attaquants opportunistes. Les plugins et thèmes tiers représentent plus de 90% des vulnérabilités WordPress selon l'équipe Wordfence — des milliers de CVE découvertes chaque année dans l'écosystème des 59 000 plugins disponibles. WPScan est le scanner de sécurité WordPress de référence : développé en Ruby par Slicer et maintenu par WPScan LLC, il intègre WPVulnDB, une base de données spécialisée contenant plus de 52 000 vulnérabilités WordPress référencées avec scores CVSS, versions affectées et disponibilité de patch. Contrairement à un scanner web généraliste comme Nikto, WPScan comprend l'architecture WordPress et peut énumérer avec précision les plugins installés, leurs versions et les CVE associées, les thèmes actifs et inactifs, les comptes utilisateurs et les hachages de mots de passe via XML-RPC. Ce guide couvre l'installation, l'obtention et l'utilisation de l'API token, l'énumération complète, le brute force, les options de discrétion, l'interprétation des résultats et les recommandations de hardening post-audit. WPScan est un outil à usage légal uniquement : utilisez-le exclusivement sur des sites dont vous êtes propriétaire ou pour lesquels vous disposez d'une autorisation de test explicite.

Présentation de WPScan : Architecture, WPVulnDB et Cas d'Usage

WPScan est écrit en Ruby et utilise l'écosystème RubyGems pour ses dépendances. Il fonctionne en mode black-box : il envoie des requêtes HTTP au site cible sans accès au code source ni à la base de données, simulant exactement ce qu'un attaquant externe peut observer. Cette approche black-box est précieuse pour valider l'exposition réelle d'un site WordPress.

Le point différenciant de WPScan est sa base de données WPVulnDB. Contrairement aux bases CVE génériques, WPVulnDB est 100% dédiée à l'écosystème WordPress avec :

• Vulnérabilités WordPress core (toutes versions depuis 1.0)
• Vulnérabilités de plugins (59 000+ plugins référencés)
• Vulnérabilités de thèmes (8 000+ thèmes référencés)
• Scores CVSS 3.1 pour chaque CVE
• Versions affectées et version de correction
• Liens vers les PoC (Proof of Concept) publics quand disponibles

L'accès à WPVulnDB nécessite un API token. Le plan gratuit autorise 25 requêtes API par jour — suffisant pour des scans occasionnels. Les plans payants (à partir de 25 USD/mois) offrent des requêtes illimitées, adaptées aux MSP ou aux équipes sécurité gérant de nombreux sites WordPress.

Cas d'usage légitimes : audit de sécurité de votre propre site WordPress avant mise en production, vérification mensuelle des plugins vulnérables dans le cadre d'une gestion des vulnérabilités, pentest web autorisé sur un site client, scan dans un programme Bug Bounty WordPress.

Installation de WPScan : Gem, Docker et Kali Linux

Installation via RubyGems (recommandée) :

# Prérequis Ruby 2.6+
ruby --version

# Installation WPScan
gem install wpscan

# Vérification
wpscan --version

Installation sur Kali Linux :

# WPScan est pré-installé dans Kali
wpscan --version

# Mise à jour
wpscan --update

Installation via Docker (recommandée pour isolation) :

# Pull de l'image officielle
docker pull wpscanteam/wpscan

# Utilisation
docker run -it --rm wpscanteam/wpscan --url https://target.com --api-token VOTRE_TOKEN

# Alias pratique
alias wpscan="docker run -it --rm wpscanteam/wpscan"

Obtention de l'API token : créez un compte sur wpscan.com (gratuit), accédez à votre profil → API Token. Copiez le token — vous ne pourrez plus le voir après la première affichage. Configurez-le dans WPScan :

# Via option CLI
wpscan --url https://target.com --api-token VOTRE_TOKEN_ICI

# Via fichier de configuration (évite de passer le token en CLI)
cat > ~/.wpscan/scan.yml << EOF
cli_options:
  api_token: VOTRE_TOKEN_ICI
EOF

Stocker le token dans le fichier de configuration est plus sécurisé que de le passer en CLI — il n'apparaît pas dans l'historique shell ni dans les logs de processus.

Scan de Base et Détection WordPress

Le scan de base détecte automatiquement la version WordPress, l'URL de login, les thèmes actifs et vérifie les CVE core :

wpscan --url https://target.com --api-token $WPSCAN_TOKEN

WPScan commence par confirmer que la cible est bien un site WordPress (détection via le chemin /wp-login.php, le fichier /wp-includes/, les métadonnées HTML). Si la cible n'est pas WordPress, le scan s'arrête immédiatement.

Résultats typiques d'un scan basique :

[+] URL: https://target.com/
[+] WordPress version 6.4.1 identified
[i] The main theme could not be detected.
[+] WordPress readme found: https://target.com/readme.html
[+] The external WP-Cron seems to be enabled
[!] WordPress version 6.4.1 identified (Insecure since 6.4.3)
 | Found By: Rss Generator (Passive Detection)
 | [!] 3 vulnerabilities identified:

Le fichier readme.html expose publiquement la version WordPress — il devrait être supprimé ou son accès restreint en production.

Énumération des Plugins : Vulnérables et Tous

L'énumération des plugins est la fonctionnalité la plus utile de WPScan car les plugins représentent la majorité des vecteurs d'attaque WordPress :

# Tous les plugins (méthode passive + active)
wpscan --url https://target.com --api-token $TOKEN --enumerate p

# Plugins vulnérables uniquement (plus rapide)
wpscan --url https://target.com --api-token $TOKEN --enumerate vp

# Plugins avec détection agressive (plus de requêtes, plus de détections)
wpscan --url https://target.com --api-token $TOKEN --enumerate ap 
  --plugins-detection aggressive

La méthode de détection passive analyse le HTML de la page d'accueil (mentions de plugins dans les scripts/styles). La méthode aggressive teste des milliers de chemins connus — beaucoup plus exhaustive mais génère 10 à 50 fois plus de requêtes.

Exemple de résultat avec CVE :

[+] contact-form-7
 | Location: https://target.com/wp-content/plugins/contact-form-7/
 | Last Updated: 2024-01-15T10:00:00.000Z
 | Readme: https://target.com/wp-content/plugins/contact-form-7/readme.txt
 | Version: 5.7.5 (latest is 5.8.1)
 |
 | [!] 1 vulnerability identified:
 |
 | [!] Title: Contact Form 7 < 5.8.1 - Reflected XSS via 'active-tab'
 |     Fixed in: 5.8.1
 |     References:
 |      - https://wpscan.com/vulnerability/xxxx-yyyy
 |      - CVE-2024-XXXXX (CVSS: 6.1 Medium)

Énumération des Thèmes et Identification Versions

# Tous les thèmes
wpscan --url https://target.com --api-token $TOKEN --enumerate t

# Thèmes vulnérables uniquement
wpscan --url https://target.com --api-token $TOKEN --enumerate vt

# Thèmes avec détection agressive
wpscan --url https://target.com --api-token $TOKEN --enumerate at 
  --themes-detection aggressive

Les thèmes incluent souvent le thème parent (framework comme Divi, Genesis, Astra) et les thèmes enfants. WPScan détecte les deux et vérifie les CVE associées. Les thèmes premium non mis à jour sont une source fréquente de vulnérabilités — en particulier les page builders comme Elementor et Divi qui ont des mises à jour de sécurité régulières.

Énumération des Utilisateurs : Méthodes et Risques

L'énumération des utilisateurs WordPress est possible via plusieurs vecteurs natifs. WPScan les teste tous :

# Énumération des utilisateurs
wpscan --url https://target.com --api-token $TOKEN --enumerate u

# Plage d'IDs à tester (par défaut 1-10)
wpscan --url https://target.com --api-token $TOKEN --enumerate u[1-25]

Méthodes d'énumération utilisées :

• JSON API : /wp-json/wp/v2/users expose les noms d'utilisateurs en JSON si non désactivé
• Author archives : /?author=1 redirige vers /author/NOM_USER/ si les archives auteur sont activées
• Login error messages : WordPress indique par défaut si le nom d'utilisateur est correct ("Mot de passe incorrect") vs inconnu ("Ce nom d'utilisateur ne correspond à aucun compte")
• Sitemap XML : les sitemaps incluent parfois des URLs d'archives auteur

La connaissance des noms d'utilisateurs est le premier pas vers une attaque par brute force. C'est pourquoi la remédiation post-audit inclut toujours la désactivation de la JSON API utilisateurs et la normalisation des messages d'erreur de login.

La sécurisation des accès utilisateurs est directement liée aux principes d'Active Directory pour les déploiements WordPress en enterprise avec LDAP/SSO.

Brute Force XML-RPC et Authentification

WordPress expose par défaut xmlrpc.php, une API legacy qui présente un risque de brute force amplifiée : une seule requête XML-RPC peut tester des centaines de paires utilisateur/mot de passe en une seule connexion (méthode system.multicall), contournant les limites de tentatives de login classiques.

# Brute force sur le formulaire de login standard
wpscan --url https://target.com 
  --usernames admin,administrator 
  --passwords /usr/share/wordlists/rockyou.txt

# Brute force ciblé via XML-RPC (plus rapide)
wpscan --url https://target.com 
  --usernames admin 
  --passwords wordlist.txt 
  --password-attack xmlrpc-multicall

# Brute force limité à 5 threads
wpscan --url https://target.com 
  --usernames admin 
  --passwords wordlist.txt 
  --max-threads 5

En pratique, le brute force WordPress avec WPScan est efficace contre des comptes avec des mots de passe faibles (liste rockyou.txt). Les comptes avec MFA ou des mots de passe complexes ne sont pas vulnérables à cette attaque. Utilisez le brute force uniquement dans le cadre d'un pentest autorisé — c'est une action particulièrement agressive.

Options de Discrétion : Random-Agent et Throttle

WPScan génère un volume de requêtes visible dans les logs serveur et les WAF. Pour réduire le bruit :

# User-Agent aléatoire (évite les blacklists par User-Agent)
wpscan --url https://target.com --random-user-agent --api-token $TOKEN

# Délai entre les requêtes (throttle en millisecondes)
wpscan --url https://target.com --throttle 2000 --api-token $TOKEN
# Ajoute un délai de 2 secondes entre chaque requête

# Combinaison discrétion maximale
wpscan --url https://target.com 
  --random-user-agent 
  --throttle 3000 
  --api-token $TOKEN 
  --enumerate vp,vt,u 
  --plugins-detection passive

Avec --throttle 3000, un scan complet prend 20 à 60 minutes au lieu de 2 à 5 minutes. Ce trade-off est justifié uniquement si vous cherchez à éviter les alertes de rate limiting ou à ne pas impacter les performances du serveur cible.

Pour un scan derrière proxy Burp :

wpscan --url https://target.com --proxy http://127.0.0.1:8080 
  --disable-tls-checks --api-token $TOKEN

Interprétation des Résultats : CVE, CVSS et Plan de Remédiation

WPScan structure ses résultats en plusieurs sections : informations générales du site, version WordPress, plugins, thèmes, utilisateurs et config items. Chaque vulnérabilité inclut :

• Titre descriptif de la vulnérabilité
• Version fixe (la version du plugin/thème qui corrige)
• Score CVSS (Critical ≥9.0, High 7.0-8.9, Medium 4.0-6.9, Low 0.1-3.9)
• Références : CVE-XXXX, lien WPScan, éventuels PoC publics

Priorisation des remédations :

1. Critiques CVSS ≥9 (RCE, injection non authentifiée) : patch immédiat
2. High CVSS 7-8.9 (XSS réfléchi authentifié, LFI) : patch sous 48h
3. Medium CVSS 4-6.9 (information disclosure, CSRF) : patch dans la semaine
4. Low CVSS <4 (headers manquants, version exposée) : planifier dans le sprint suivant

Combinez les résultats WPScan avec un scan pentest réseau complet pour une vue exhaustive de la surface d'attaque.

Recommandations de Hardening Post-Audit WordPress

Les findings WPScan alimentent directement un plan de hardening WordPress. Voici les mesures de remédiation prioritaires :

Désactiver XML-RPC :

# Dans .htaccess (Apache)
<Files xmlrpc.php>
    Order Deny,Allow
    Deny from all
</Files>

# Via functions.php (désactive toutes les requêtes XML-RPC)
add_filter('xmlrpc_enabled', '__return_false');

Protéger wp-config.php :

# Dans .htaccess
<Files wp-config.php>
    Order Deny,Allow
    Deny from all
</Files>

Désactiver l'édition de fichiers depuis l'admin :

# Dans wp-config.php
define('DISALLOW_FILE_EDIT', true);

Masquer la version WordPress :

# Dans functions.php
remove_action('wp_head', 'wp_generator');
// Supprime la balise meta generator

Sécuriser l'énumération utilisateurs :

# Dans functions.php - désactiver la JSON API utilisateurs
add_filter('rest_endpoints', function($endpoints) {
    if (isset($endpoints['/wp/v2/users'])) {
        unset($endpoints['/wp/v2/users']);
    }
    return $endpoints;
});

Authentification 2FA : installez un plugin MFA (WordFence Login Security, Two Factor) pour le compte admin. Cela rend le brute force inefficace même si le mot de passe est compromis.

WAF : activez Cloudflare WAF ou installez Wordfence avec le mode firewall actif pour bloquer les scans automatisés et les tentatives d'exploitation.

Export du Rapport et Intégration CI/CD

# Export texte (le plus simple)
wpscan --url https://target.com --api-token $TOKEN 
  --output rapport_wpscan.txt --format cli-no-colour

# Export JSON (pour traitement programmatique)
wpscan --url https://target.com --api-token $TOKEN 
  --output rapport_wpscan.json --format json

L'intégration de WPScan dans un pipeline CI/CD (GitHub Actions, GitLab CI) permet d'automatiser les scans de sécurité WordPress à chaque déploiement :

# Exemple GitHub Actions
- name: WPScan Security Check
  run: |
    docker run --rm wpscanteam/wpscan 
      --url ${{ secrets.WP_URL }} 
      --api-token ${{ secrets.WPSCAN_TOKEN }} 
      --enumerate vp,vt 
      --format json > wpscan-results.json
    
    # Fail le build si des vulnérabilités critiques sont trouvées
    cat wpscan-results.json | python3 -c "
    import json, sys
    data = json.load(sys.stdin)
    vulns = [v for p in data.get('plugins',{}).values() 
             for v in p.get('vulnerabilities',[]) 
             if v.get('cvss',{}).get('score',0) >= 7.0]
    sys.exit(1 if vulns else 0)"

Cette approche DevSecOps détecte les nouvelles vulnérabilités de plugins dès leur publication dans WPVulnDB, avant qu'elles ne soient exploitées en production.

Questions fréquentes sur WPScan