Au sommaire de ce dossier :
- Introduction
- Des correctifs de sécurité disponibles avant que les failles ne soient connues
- La WordPress Security Team
- HackerOne
- Mise à jour automatiques du cœur WP
- WordPress apprend de ses erreurs
- Sécurité des extensions et des thèmes : outils indispensables
- Mises à jour automatiques des thèmes et extensions
- Quid des extensions premium ou indépendantes ?
- Que faire si je reçoit un email indiquant que mon site a une faille ?
- Comment (bien) gérer la sécurité de mon parc de sites WordPress ?
En propulsant plus de 40 % du web, WordPress est logiquement le CMS le plus attaqué ! C’est grave ?
En juillet 2025, WordPress est utilisé par 43,5 % des sites web. Encore plus frappant, il propulse 61 % des sites qui utilisent un CMS [1]. Avec de telles parts de marché, WordPress est forcément plus ciblé que les autres logiciels de gestion de contenu concurrents.
Si WordPress est plus attaqué que les autres, c’est tout simplement qu’une faille de sécurité affectant ce CMS affectera mécaniquement davantage de sites. WP est donc une cible particulièrement intéressante pour les hackers.
Cela se vérifie dans les faits : en 2024, l’écosystème WordPress a fait l’objet de 7966 failles de sécurité publiquement rapportées dans le programme CVE (recueil des informations publiques relatives aux vulnérabilités de sécurité informatique). Cela représente en moyenne 22 nouvelles failles de sécurité découvertes par jour. C’est beaucoup, et on a d’ailleurs noté une augmentation de 34 % entre 2023 et 2024 [2].
Attention cependant à correctement interpréter ses chiffres !
Premièrement, il ne s’agit généralement pas de failles liées à WordPress lui-même, mais en écrasante majorité de failles trouvées dans des extensions de l’écosystème. 96 % des failles proviennent d’extensions, 4 % proviennent de thèmes, et seulement 7 failles de sécurité concernaient le cœur du CMS WordPress en 2024 [3].
Deuxièmement, ces chiffres concernent le nombre de failles de sécurité publiquement connues de l’écosystème WordPress. Toutes ces failles n’ont pas forcément été exploitées pour pirater des sites. C’est tout simplement le nombre de rapports de sécurité concernant WordPress qui ont été ouverts en 2024 auprès de l’organisme MITRE, qui gère le programme CVE au niveau international.
WordPress est certes le CMS le plus attaqué, mais c’est surtout celui qui fait l’objet du plus grand nombre de corrections de sécurité !
WordPress est donc une cible de choix pour les pirates, mais son poids dans l’écosystème numérique lui permet aussi de disposer de ressources que ne peuvent pas se permettre d’autres CMS : équipe dédiée à la sécurité, programme de surveillance des failles, communauté de développeur·euses la plus importante sur le marché des CMS… il n’est pas vraiment possible de comparer WP à la concurrence côté CMS tant le différentiel en termes de parts de marché et de moyens disponibles est grand.
Bien qu’il soit une cible de choix, le cœur de WordPress n’a pas connu de faille de sécurité zero-day depuis plus de 10 ans, sachant que nous parlons d’un CMS qui vient de souffler ses 22 bougies.
Glossaire : une faille de sécurité dite « zero-day » est une vulnérabilité qui a été exploitée avant qu’un correctif ne soit disponible.
Les risques de sécurité associés à WordPress sont davantage liés à un défaut de maintenance (absence de mise à jour) que de vulnérabilités directes du logiciel.
Des correctifs de sécurité généralement disponibles avant que les failles ne soient connues
Ces failles de sécurité sont généralement découvertes par des chercheurs indépendants, puis remontées aux équipes de développement de l’extension, du thème ou du cœur WP, pour correction.
Ce n’est qu’après sa correction que la faille de sécurité est rendue publique, souvent après un délai, pour s’assurer qu’une majorité des sites ont été mis à jour.
Les pirates exploitent donc très majoritairement des failles qui ont déjà fait l’objet d’un correctif, en espérant tomber sur des sites utilisant une version obsolète d’un thème ou d’une extension.
Si vous avez une politique de maintenance sérieuse, alors lorsque une faille de sécurité est connue publiquement, votre site est déjà protégé contre celle-ci. Mais cela dépend donc de la fréquence à laquelle vous faites vos mises à jour.
C’est relativement simple : plus vite vous effectuez les mises à jour de votre site, plus vite il sera protégé contre les vulnérabilités. À l’inverse, plus vous attendez, plus vous prenez le risque qu’une faille connue publiquement commence à être exploitée.
L’organisme qui recense le plus grand nombre de rapports de failles est actuellement Patchstack, une entreprise spécialisée dans la sécurité WordPress. La base de données de vulnérabilités de Patchstack est la plus utilisée par les acteurs de l’écosystème.
Vous cherchez un prestataire expert en maintenance et impliqué au quotidien dans la sécurité de l’écosystème WordPress ? L’agence Whodunit est sans doute l’un des interlocuteurs les plus pertinents sur le sujet en France.
La gestion des correctifs de sécurité dans le cœur WP
La WordPress Security Team : une équipe d’experts en cybersécurité
WordPress dispose d’une équipe dédiée à la sécurité du logiciel, réunissant une trentaine de membres actifs. Certains sont rémunérés pour ce rôle, d’autres sont totalement bénévoles. Le représentant de l’équipe est actuellement l’ingénieur John Blackbourn, également responsable de la sécurité de l’agence britannique Human Made.
L’équipe se réunit plusieurs fois par an, mais la majeure partie de son travail s’effectue de façon asynchrone, ses membres étant répartis sur tous les continents.
Bon à savoir : deux des membres de l’équipe de sécurité sont localisés en France. Alex Concha, expert sécurité travaillant chez Automattic, et moi-même, Jb Audras, directeur technique de Whodunit. Pour l’anecdote, nous habitons tous deux en Ardèche
:)
Les principales responsabilités de l’équipe de sécurité de WP sont les suivantes :
- Trier les rapports de vulnérabilité. Cela concerne le cœur de WordPress, ainsi que d’autres projets officiels et l’infrastructure WordPress.org.
- Coordonner les correctifs de sécurité, le renforcement des mesures de protection et la publication des mises à jour de sécurité du CMS.
- Vérifier les nouvelles fonctionnalités proposées pour le cœur de WordPress afin de s’assurer que les normes de sécurité sont respectées.
L’équipe de sécurité collabore avec des représentants de nombreux hébergeurs et fournisseurs de services à travers le monde. Cette relation facilite une coordination directe en matière de sécurité avec ces partenaires, qui gèrent des dizaines de millions d’installations WordPress, afin de garantir le plus haut niveau de sécurité possible [4].
HackerOne, un programme de remontée responsable des failles de sécurité
Depuis des années, WordPress.org utilise HackerOne pour gérer les remontées de failles de sécurité concernant le cœur du CMS, les sites et services de l’écosystème ainsi que les extensions officielles.
Ce programme dit de « bug bounty » permet aux personnes qui ont découvert une faille de sécurité potentielle de la remonter de façon confidentielle à l’équipe Security.
Si la faille de sécurité est avérée, le chercheur à l’origine de la découverte est alors rémunéré. Depuis 2017, WordPress.org a ainsi offert plus de 80 000 dollars aux 238 personnes qui ont utilisé ce programme pour remonter un problème de sécurité de façon responsable. Ces personnes sont aussi créditées publiquement pour leur découverte.
Le programme white hat HackerOne est un dispositif gagnant-gagnant, la rémunération des « hackers responsables » ainsi que les gains en réputation qui en découlent étant plus valorisant que l’exploitation des failles trouvées.
Les mises à jour de sécurité de WP sont automatisables depuis plus de 12 ans
Cela fait depuis 2013 – avec la version 3.7 « Count Basie » – que les mises à jour du cœur du CMS WordPress sont automatisables. Auparavant, il fallait manuellement télécharger WordPress afin de le mettre à jour dans sa dernière version.
Depuis 2020, les mises à jour de maintenance et de sécurité (mises à jour dites « mineures » du CMS) sont activées par défaut sur tous les sites WordPress. Vous n’avez ainsi même pas à vous connecter en back-office pour les effectuer.
J’ai eu le plaisir de diriger le développement de cette fonctionnalité de mise à jour automatique du cœur WP. Elle a été intégrée lors de la sortie de WordPress 5.6 « Simone » et c’est évidemment une grande fierté d’avoir contribué à sécuriser davantage plus de 40 % du web [5].
Ça fait plus de 10 ans que le cœur de WordPress n’a pas connu de faille zero-day. Cela date de la version 4.1.2 qui corrigeait en 2015 une faille de sécurité qui avait déjà commencé à être exploitée [6].
Un jeu de tests unitaires de sécurité, parce que WordPress apprend de ses erreurs
La Security Team de WordPress dispose d’un jeu de tests unitaires automatiquement lancé à chaque modification de code dans le cœur du CMS.
Ces tests ne sont pas disponibles publiquement pour des raisons de… sécurité. Mais sachez qu’ils recensent toutes les failles de sécurité précédemment découvertes sur le CMS, et plus généralement un bon paquet de règles de sécurité documentées dans l’industrie web.
Ces tests permettent au quotidien de s’assurer que toute modification réalisée dans le code source de WP n’apporte pas une faille de sécurité. En cas de non conformité, le jeu de tests alerte l’équipe de sécurité afin de pouvoir proposer un correctif immédiatement.
Chaque nouvelle version du CMS est évidemment passée au crible de ce jeu de tests.
Sécurité des extensions et des thèmes de l’écosystème : quelques outils indispensables
L’auteur·ice (ou l’équipe de développement) de chaque extension et thème est bien évidemment responsable de la sécurisation de son code. Mais ces personnes ne sont pas seules au monde à assurer la sécurité de leur bouts de code ! Les gens qui développent des extensions pour WordPress sont épaulées pour cette tâche.
Pour commencer, les extensions disponibles sur le répertoire officiel WordPress.org sont toutes initalement vérifiées manuellement par l’équipe chargée de leur validation sur le répertoire : la Plugin Review Team.
Cette équipe dispose d’outils dédiés à la sécurité et chaque extension proposée à la diffusion est méthodiquement analysée de façon à la fois manuelle et automatisée, afin d’éliminer toute vulnérabilité potentielle.
Un outil de vérification de la sécurité de vos extensions WordPress
Depuis peu, une partie de ces outils ont été mis à disposition des développeurs et développeuses d’extensions. L’outil clé est l’extension Plugin Checker (PCP).
Cette extension vous permet de réaliser de vous même une grande partie des tests de sécurité sur les extensions que vous développez (ou que vous utilisez).
PCP fait bien plus que vérifier la sécurité de vos extensions. Elle remonte aussi les problèmes éventuels de conformité vis à vis des guidelines du répertoire officiel. Mais rien que pour ses checks de sécurité, cette extension est précieuse.
Vérifier automatiquement la sécurité de vos thèmes WordPress
L’équipe de validation des thèmes sur le répertoire officiel dispose elle aussi de son extension de vérification automatisée.
Là encore, l’extension fait bien plus que vérifier la sécurité du code produit, mais ses vérifications de sécurité sont solides et vous permettent de vous assurer de la qualité du code de votre thème.
Ces extensions sont utilisables pour vérifier le code d’extensions et thèmes disponibles sur le répertoire officiel, mais aussi pour effectuer une revue de code de vos extensions et thèmes développés sur mesure par votre prestataire, ou achetés en ligne.
Les mises à jour automatiques des thèmes et des extensions
Tout comme pour le cœur du CMS, WordPress permet de configurer une mise à jour automatiques des thèmes et des extensions.
Cette fonctionnalité a été introduite avec la version majeure 5.5, et c’est là aussi une vraie fierté pour Whodunit puisque c’est nous qui l’avons développée au moyen d’un Feature Plugin.
Définition : « Feature Plugin » est un terme utilisé dans l’écosystème WP pour désigner une extension de test d’une fonctionnalité majeure avant son introduction dans le cœur du CMS.
C’est donc en 2020 que notre extension WP AutoUpdates a été introduite dans WordPress, après 8 mois de travail acharné sur son développement [7]. Elle faisait à l’époque partie des 9 grands projets majeurs pour le CMS WordPress, et nous avons dirigé celui-ci du début à la fin.
Cette fonctionnalité est dite « opt-in », c’est-à-dire qu’elle n’est pas activée par défaut : vous devez choisir extension par extension celles que vous voulez mettre à jour automatiquement et celles qui doivent être mises à jour manuellement.
Que vous activiez ou non les mises à jour automatiques sur votre site, ce qui compte c’est que vous ayez une politique de maintenance « au fil de l’eau ».
Chaque mise à jour doit idéalement avoir lieu dans les jours suivant sa sortie, 7 jours ouvrés étant un compromis relativement acceptable, sauf en cas de faille de sécurité critiques bien entendu.
Quelle est la bonne stratégie à adopter pour les mises à jour des extensions ?
On entend souvent des prestataires (indépendants ou agences) dire qu’il vaut mieux attendre avant de lancer les mises à jour, histoire d’attendre que les bugs de la version soient corrigés après les retours des gens qui ont eu de la casse sur leur site.
Disons-le franchement : ce n’est pas vraiment une politique de maintenance à recommander.
Votre politique de gestion des mises à jour de votre site WordPress doit être définie à travers le prisme d’une problématique de gestion du risque cyber.
Si vous évitez de réaliser des mises à jour de WordPress, d’extensions ou de thèmes, au motif que cela peut casser potentiellement quelque chose, vous demeurez de toute façon dans l’incertitude au final, car vous serez bien obligé·e de la faire un jour, cette fichue mise à niveau. D’autant plus lorsqu’une mise à jour de sécurité corrigeant une vulnérabilité importante sortira. Dans ce cas, vous n’aurez pas d’autre choix que de mettre à jour votre site, en urgence.
Mon opinion sur le sujet en tant que directeur technique de Whodunit, de personne assez bien identifiée comme précurseur dans la mise en place de politiques de maintenance de sites WordPress, et de membre de l’équipe de sécurité du CMS, c’est qu’ en terme de gestion du risque, il est moins coûteux d’effectuer une mise à jour que de payer le prix de son absence
Cela n’empêche évidemment pas de prendre toutes les précautions nécessaires : désactiver les mises à jour automatiques sur l’instance de production, mais les activer en staging ou en instance de pré-production permet par exemple d’avoir une instance du site constamment à jour et testable, tandis que les mises à jour sont déployées en production de façon hebdomadaire.
À vous de trouver la procédure de gestion du risque cyber qui convient à votre installation WordPress.
Quid des extensions premium ou indépendantes ?
Les extensions premium et a fortiori les extensions proposées sur des dépôts indépendants échappent forcément à la vigilance des équipes de WordPress.org. Mais cela ne veut pas dire qu’elles ne sont pas sécurisées, ni qu’elles ne font l’objet d’aucun suivi.
Nous avons d’un côté les poids lourds du secteurs, qui disposent d’un programme de bug bounty permettant de rémunérer les personnes qui chassent les failles de sécurité et les remontent de façon responsable.
D’un autre côté, toutes les extensions, qu’elles soient disponibles ou non sur le répertoire officiel peuvent être la cible de tests de contributeurs et contributrices à Patchstack ou autre acteur de la cybersécurité.
J’ai par exemple de mon côté ces dernières années décelé plusieurs failles de sécurité que j’ai remonté de façon responsable et confidentielle aux acteurs du secteur. Sur de petites extensions gérées par des petites équipes, cela se passe par le simple envoi d’un email expliquant le problème et apportant une solution.
Sur d’autres extensions plus importantes, je suis passé par le programme de bug bounty de l’extension et j’ai reçu une prime de l’équipe de développement de l’extension pour me remercier d’avoir remonté le problème. Ce fut par exemple le cas avec l’éditeur Yoast qui est très attentif et très bien organisé sur les questions de sécurité.
Ces primes peuvent aller de quelques centaines à plusieurs milliers d’euros. La plus grosse prime de l’histoire de l’écosystème WordPress ayant été de 16400$, versés par Patchstack pour récompenser la remontée d’une faille très importante (tant en criticité qu’en volume de sites concernés) trouvée sur l’extension Litespeed Cache.
La découverte de failles de sécurité devient donc un enjeu économique s’appuyant sur la progression des politiques de gestion du risque cyber dans la plupart des organisations.
Que faire si je reçois un email m’indiquant que mon site a une faille ?
Il arrive parfois de recevoir des emails indiquant remonter une vulnérabilité découverte sur votre site. La pertinence de ces emails est assez variable.
Lorsque une faille est publiquement connue, par exemple sur une version spécifique d’une extension WordPress, beaucoup de petits malins ont compris qu’il pourrait être potentiellement plus rémunérateur – et moins risqué – de contacter les organisations utilisant cette version de l’extension pour leur indiquer la présence d’une faille de sécurité que de l’exploiter directement.
Ces personnes utilisent alors un peu d’automatisation pour trouver des sites concernés, puis pour dégoter une adresse email ou pour envoyer un email manuel via le formulaire de contact. Parfois elles passent même par des agences intermédiaires qui s’occupent de tout.
Il n’est donc pas rare pour les DSI françaises de recevoir des emails indiquant que tel ou tel site de leur parc présente une vulnérabilité. En proposant – moyennant finance – de communiquer les détails de la faille trouvée. L’objectif est de récolter plus d’argent que par l’exploitation directe de la vulnérabilité.
Pour tout dire, il est assez rare que ces sollicitations soient très qualifiées. Elles sont généralement générées automatiquement par des scripts. Le plus simple est de les transmettre à votre prestataire qui se fera une joie (ou pas, suivant sa maturité sur le sujet) d’analyser la situation et de vous dire quoi faire. Toujours en suivant les bonnes pratiques de gestion du risque cyber : évaluation du risque, priorisation, planification, documentation.
En tout état de cause, ne payez jamais de récompense sans avoir demandé au préalable des détails sur l’origine de la faille de sécurité. Si vous ne recevez pas de réponse à vos questions, oubliez l’e-mail reçu, c’est probablement de l’automatisation pure et simple.
Comment (bien) gérer la sécurité de mon parc de sites WordPress ?
- Disposer d’une politique de maintenance pour vos sites, et plus particulièrement d’une politique de mise à jour et de gestion des sauvegardes.
- Réaliser ou faire réaliser un audit de sécurité de votre site WordPress, qui permettra d’évaluer le niveau de sécurité de votre installation et d’identifier les éventuelles failles de sécurité potentielles.
- D’une manière générale, mettre en place une politique de sécurité (PSSI) dans votre organisation.
- Refaire un audit d’évaluation, idéalement annuel, et après refonte du site ou changement impactant celui-ci de manière importante.
L’offre Audit de Sécurité de Whodunit Consulting
Nous proposons un audit de sécurité de votre installation WordPress, qui peut être réalisé de façon ponctuelle ou régulière.
La valeur ajoutée de Whodunit Consulting : des recommandations directement applicables dans le contexte de votre site et spécialisées pour WordPress, proposées par un membre de la Security Team du CMS !
Politique de maintenance, qualité du thème, de vos extensions, configuration du CMS et sécurité serveur, nous passons votre cible au crible de notre checklist de sécurité. Nous sommes aussi capables de réaliser des tests d’intrusion (pentests).
Sources citées dans cet article :
- [1] Source : statistiques WordPress de W3Techs disponibles en juillet 2025 (en anglais).
- [2][3] Source : State of WordPress Security in 2025, par Patchstack (en anglais).
- [4] Pour en savoir plus, lire l’interview de John Blackbourn, qui dirige actuellement l’équipe de sécurité de WordPress (en anglais).
- [5] Source : annonce de sortie de la fonctionnalité de mise à jour automatique du cœur WP sur le blog Make/Core, par Jean-Baptiste Audras (en anglais)
- [6] Source : communiqué de sortie de WordPress 4.2.1 (en anglais)
- [7] Source : Merge Announcement: Plugins & Themes Auto-Updates, sur le site Make/Core par Jb Audras (en anglais)
Laisser un commentaire