WordPress fait tourner plus de 40 % des sites web dans le monde, et la quasi-totalité des incidents de sécurité qui le touchent ne viennent pas du cœur du logiciel, mais des extensions installées dessus. Le constat revient chaque année dans les rapports du secteur : les plugins et les thèmes concentrent l’essentiel de la surface d’attaque réelle d’un site WordPress.
Le décalage entre publication et découverte
Une vulnérabilité dans un plugin n’est pas toujours connue au moment où elle existe. Un chercheur en sécurité la découvre, la signale au développeur de façon responsable, le développeur publie un correctif, puis la vulnérabilité est référencée publiquement avec un identifiant CVE (Common Vulnerabilities and Exposures) dans des bases comme la National Vulnerability Database ou des bases spécialisées WordPress comme WPScan ou Patchstack.
Ce délai, entre la sortie du correctif et le moment où l’administrateur du site l’applique réellement, est exactement la fenêtre que les attaquants automatisés exploitent. Une fois une CVE publiée, des scanners de masse commencent à sonder tous les sites WordPress accessibles pour repérer ceux qui tournent encore avec la version vulnérable. Ce n’est pas une attaque ciblée : c’est un ratissage automatique qui ne demande aucune compétence particulière à celui qui le lance.
Pourquoi la mise à jour automatique ne suffit pas toujours
WordPress propose des mises à jour automatiques pour le cœur et, depuis plusieurs versions, pour les plugins si l’option est activée. Mais dans la pratique, beaucoup de sites gardent cette option désactivée par prudence, pour éviter qu’une mise à jour casse une fonctionnalité en production sans supervision humaine. Résultat : la mise à jour existe, elle est disponible, mais personne ne l’applique tant que personne ne va vérifier manuellement la liste des plugins installés.
Sur un site avec quinze ou vingt extensions actives, ce qui est courant, cette vérification manuelle régulière est rarement faite avec la rigueur qu’elle demanderait. On lance l’extension une fois à l’installation et on l’oublie, jusqu’au jour où elle devient le point d’entrée d’un incident.
Ce qu’un scan de vulnérabilités doit apporter concrètement
Un scan utile ne se contente pas de dire « vulnérabilité trouvée ». Pour être exploitable par quelqu’un qui gère le site, il doit donner l’identifiant CVE précis, la sévérité réelle (une faille XSS n’a pas le même impact qu’une exécution de code à distance), et un lien vers la source qui documente le problème, pour que l’administrateur puisse juger lui-même de l’urgence plutôt que de faire confiance aveuglément à un score automatique.
L’autre point qui change tout en pratique, c’est la fréquence. Un scan manuel ponctuel donne une photo à un instant T, qui devient obsolète dès qu’une nouvelle CVE sort sur l’un des plugins installés. Un scan automatisé qui tourne chaque jour et qui alerte uniquement quand quelque chose de nouveau apparaît change la nature du travail : on passe d’une vérification qu’il faut se souvenir de faire à une alerte qui arrive d’elle-même.
Sources utiles pour qui veut suivre ce sujet de près : le flux de vulnérabilités de WPVulnerability, les bulletins de sécurité officiels sur WordPress.org, et le guide de durcissement de l’OWASP sur WordPress.
Leave a Reply