Vulnérabilités plugins et thèmes WordPress : 3 tests qui révèlent votre surface d'attaque
70 % des sites WordPress hackés le sont via un plugin obsolète. Orilyt scanne le HTML, identifie chaque plugin et thème installé, puis croise les versions avec la base de vulnérabilités WPScan.
- Le test #47 détecte les plugins installés en scannant les chemins /wp-content/plugins/ dans le HTML, et extrait les numéros de version via les paramètres ?ver= des assets
- Le test #46 identifie le thème actif en analysant les chemins /wp-content/themes/ — un thème obsolète ou piraté est un vecteur d'attaque courant
- Le test #15 croise les versions détectées avec la base de vulnérabilités WPScan : CVE connues, score CVSS, version corrigée — c'est le constat le plus alarmant pour un client
WordPress propulse plus de 40 % du web. Cette popularité en fait la cible numéro un des attaquants. Et le maillon faible n'est presque jamais le cœur de WordPress lui-même — ce sont les plugins. Selon les données de Patchstack et WPScan, environ 70 % des sites WordPress compromis le sont via une faille dans un plugin ou un thème obsolète.
Le problème est que la plupart des propriétaires de sites ne savent même pas quels plugins sont visibles de l'extérieur. Chaque plugin laisse des traces dans le code HTML : des chemins vers /wp-content/plugins/, des fichiers CSS et JavaScript avec des paramètres de version. Pour un attaquant, c'est une carte routière.
Orilyt exécute trois tests complémentaires pour cartographier cette surface d'attaque. Le test #47 détecte les plugins exposés et leurs versions. Le test #46 identifie le thème actif. Le test #15 croise ces informations avec la base de vulnérabilités WPScan pour révéler les CVE connues. Ensemble, ils transforment une vérification technique en argument commercial immédiat.
Test #47 : Quels plugins sont visibles depuis l'extérieur ?
Le test #47 analyse le code HTML de la page pour détecter les plugins WordPress installés. Il ne se connecte pas au back-office — il regarde simplement ce qui est visible publiquement. La méthode :
- Scan des chemins — chaque occurrence de /wp-content/plugins/{slug}/ dans le HTML est extraite. Le slug (identifiant unique du plugin) est collecté et dédupliqué. Exemple : si le HTML contient /wp-content/plugins/contact-form-7/css/styles.css, le plugin « contact-form-7 » est identifié
- Extraction des versions — les URLs d'assets WordPress incluent souvent un paramètre ?ver=X.Y.Z. Le test #47 analyse ces paramètres pour chaque plugin détecté. Exemple : /wp-content/plugins/elementor/assets/js/frontend.min.js?ver=3.18.2 révèle que Elementor version 3.18.2 est installé
- Comptage et scoring — le nombre de plugins détectés et le nombre de versions exposées déterminent le score. 8+ plugins avec 3+ versions exposées = score 40/100. 4+ plugins ou 2+ versions = score 55. Peu de plugins sans versions = score 75
Le test conserve jusqu'à 25 plugins et leurs versions dans les données brutes du rapport. Pour chaque plugin, jusqu'à 3 preuves (chemins trouvés) sont incluses. C'est une photographie complète de la surface d'attaque côté extensions.
Test #46 : Quel thème est exposé ?
Le test #46 utilise la même logique de scan HTML, mais cible les chemins /wp-content/themes/ :
- Détection du thème actif — chaque occurrence de /wp-content/themes/{slug}/ dans le HTML est extraite. Le thème le plus fréquent est considéré comme le thème actif (un thème enfant peut coexister avec son thème parent)
- Scoring simple — si un thème est détectable, le score est 80/100. Si aucun thème n'est visible (rare), le score est 100. L'exposition du nom de thème n'est pas une vulnérabilité en soi, mais elle ouvre la porte
Pourquoi le thème compte ? Les thèmes WordPress exécutent du code PHP côté serveur. Un thème « nulled » (piraté) contient souvent des portes dérobées. Un thème abandonné par son développeur ne recevra plus de correctifs de sécurité. Et contrairement aux plugins, le thème est chargé sur chaque page du site — la surface d'exposition est maximale.
Le test #46 fournit aussi la liste des thèmes candidats et les preuves associées, ce qui permet d'identifier la présence éventuelle d'un thème parent (comme « flavflavor ») et d'un thème enfant (comme « flavorflavor-child »).
Test #15 : Des vulnérabilités connues dans vos versions ?
C'est le test qui transforme une simple détection en signal d'alarme. Le test #15 utilise la base de données WPScan — la référence mondiale en matière de vulnérabilités WordPress — pour croiser les versions détectées avec les failles connues :
- Version du cœur WordPress — si la version de WordPress est détectable (via le meta generator ou d'autres indices), elle est envoyée à l'API WPScan. La réponse inclut toutes les CVE connues pour cette version, avec le score CVSS et la version corrigée
- Scoring basé sur les vulnérabilités — aucune CVE connue = score 100. 1 à 3 vulnérabilités = score 60 (à améliorer). Plus de 3 vulnérabilités = score 30 (critique). Si la version n'est pas détectable, le score monte à 90 (bonne pratique de masquage)
- Détail des failles — le rapport affiche jusqu'à 8 vulnérabilités avec le titre, le numéro CVE, le score CVSS et la version qui corrige le problème. C'est concret, vérifiable, et impossible à ignorer pour un client
La puissance de ce test vient de la combinaison avec les tests #47 et #46. Un client qui voit « Elementor 3.18.2 détecté » peut se rassurer. Mais s'il voit en plus « 2 CVE critiques connues pour cette version, corrigées dans 3.19.0 », l'urgence est immédiate.
Les risques concrets : pourquoi c'est urgent
Les plugins et thèmes vulnérables ne sont pas un risque théorique. Voici les scénarios les plus fréquents :
- Plugins abandonnés — un plugin qui n'a pas été mis à jour depuis 2+ ans ne recevra probablement jamais de correctif. Si une faille est découverte, elle restera ouverte indéfiniment. Le site est une cible permanente
- Versions obsolètes avec CVE — une version spécifique d'un plugin avec une CVE publiée est une invitation aux scripts automatisés. Les bots scannent le web en permanence à la recherche exacte de ces signatures version+plugin
- Thèmes « nulled » (piratés) — des thèmes premium gratuits téléchargés sur des sites tiers contiennent quasi systématiquement des portes dérobées (backdoors). Le site est compromis dès l'installation
- Accumulation de plugins — chaque plugin actif augmente la surface d'attaque. Un site avec 30 plugins a 30 points d'entrée potentiels. La règle : n'installer que le strict nécessaire
Comment se protéger : les bonnes pratiques
La bonne nouvelle : la protection contre les vulnérabilités de plugins est largement une question de discipline, pas de budget :
- Mises à jour régulières — activer les mises à jour automatiques pour les plugins et thèmes (WordPress le permet nativement depuis la version 5.5). Vérifier manuellement chaque semaine pour les mises à jour majeures
- Minimalisme — désactiver et supprimer tout plugin non utilisé. Un plugin désactivé mais présent sur le serveur reste exploitable. Viser moins de 15 plugins actifs
- Sources officielles uniquement — ne jamais installer un thème ou plugin depuis un site tiers non vérifié. Le dépôt WordPress.org et les marketplaces officielles (ThemeForest, Elegant Themes) appliquent des contrôles de sécurité
- Monitoring continu — un audit ponctuel est un bon début, mais la veille continue est essentielle. Les nouvelles CVE sont publiées chaque semaine. Orilyt permet de relancer un audit régulièrement pour détecter les dérives
Pour les freelances et agences qui gèrent des sites clients, ces pratiques ne sont pas juste des recommandations — elles sont une obligation professionnelle. Un site client compromis via un plugin obsolète que vous auriez dû mettre à jour, c'est votre responsabilité.
Valeur commerciale : le constat le plus convaincant
De tous les tests Orilyt, la détection de plugins vulnérables est probablement le constat qui génère le plus de conversions pour les freelances et agences. La raison est simple : c'est concret, c'est effrayant, et c'est vérifiable.
Dans le rapport Orilyt, les trois tests génèrent des recommandations FIA (Fait-Impact-Action) immédiates :
- Fait : « 12 plugins détectés, dont 4 avec des versions exposées. 2 CVE critiques identifiées via WPScan pour Elementor 3.18.2 »
- Impact : « Un attaquant peut cibler ces versions précises avec des exploits publics. Le risque de compromission est élevé et immédiat »
- Action : « Mettre à jour Elementor vers 3.19.0+, désactiver les plugins inutilisés, masquer les numéros de version dans le code source »
Quand un client voit la liste de ses plugins vulnérables avec les CVE associées, la conversation passe instantanément de « est-ce que j'ai besoin d'un audit ? » à « quand pouvez-vous commencer les corrections ? ». C'est l'argument de vente le plus puissant d'un audit de sécurité WordPress.
Votre surface d'attaque WordPress, cartographiée en 2 minutes
Les plugins sont la force de WordPress — et sa plus grande faiblesse. Ils étendent les fonctionnalités, mais chacun ajoute du code tiers qui doit être maintenu et surveillé. Les tests #47, #46 et #15 d'Orilyt automatisent ce travail de veille.
Le test #47 révèle quels plugins sont visibles et quelles versions sont exposées. Le test #46 identifie le thème actif. Le test #15 croise tout cela avec la base WPScan pour identifier les vulnérabilités connues. Ensemble, ils fournissent une cartographie complète de la surface d'attaque.
Pour un freelance ou une agence, ce triptyque est l'outil le plus efficace pour démontrer la valeur d'un audit de sécurité. Les résultats sont concrets, vérifiables et créent l'urgence nécessaire pour déclencher un mandat de correction.