Pourquoi les plugins WordPress sont un cauchemar en matière de sécurité - et comment EmDash y remédie

WordPress équipe plus de 40 sites %. Mais son architecture de plugins est responsable de milliers de vulnérabilités par an. Cloudflare propose une autre voie.

Un problème que WordPress ne peut pas résoudre de l'intérieur

Lorsque vous installez un plugin dans WordPress, vous lui donnez un accès complet à la base de données et au système de fichiers de l'ensemble du site. Il n'y a pas d'isolement. Le plugin de formulaire de contact a techniquement les mêmes autorisations que le plugin de gestion du commerce électronique - ils voient tous deux tout : les données de l'utilisateur, le contenu, la configuration, les détails du paiement.

Ce n'est pas la faute d'un plugin spécifique. Il s'agit d'un principe architectural de WordPress datant de 2003. Un plugin est un script PHP qui se branche directement sur le système central. WordPress lui fait entièrement confiance.

Et c'est là que le problème commence.

Des chiffres qui devraient inquiéter tous les webmasters

L'entreprise de sécurité Patchstack suit systématiquement les vulnérabilités de l'écosystème WordPress. Les données recueillies au cours des dernières années révèlent une tendance claire :

Année 2024 a apporté 7 966 nouvelles vulnérabilités, soit une augmentation de 34 % par rapport à l'année précédente. Cela représente une moyenne de 22 nouvelles failles de sécurité par jour. Parmi celles-ci, 96 % proviennent des plugins et 4 % des modèles. Seules 7 vulnérabilités ont été trouvées dans le noyau de WordPress lui-même.

Premier semestre 2025 a ajouté 6 700 vulnérabilités. Toutefois, un autre chiffre est plus important que le nombre lui-même : 41,5 % d'entre elles étaient effectivement exploitables dans la pratique, contre 30,4 % au cours de la même période de l'année dernière. L'attaquant n'a eu besoin d'aucun identifiant de connexion.

Les types de vulnérabilités les plus courants sont restés les mêmes depuis des années : XSS (Cross-Site Scripting), CSRF (Cross-Site Request Forgery), contrôle d'accès non respecté et inclusion de fichiers locaux.

Le mythe du plugin populaire

L'hypothèse la plus répandue est que les plugins bien connus, qui comptent des millions d'installations, sont sûrs parce qu'ils sont contrôlés par une large communauté. Les données indiquent le contraire.

En 2024, plus de 1 000 vulnérabilités ont été découvertes dans des plugins ayant plus de 100 000 installations actives. Des vulnérabilités critiques ont été découvertes dans des outils aussi répandus que LiteSpeed Cache, Really Simple SSL et The Events Calendar. Patchstack a versé sa prime la plus élevée en 2024 - 16 400 dollars - pour une vulnérabilité critique dans LiteSpeed Cache, un plugin comptant des millions d'utilisateurs.

La popularité n'est pas synonyme de sécurité. Elle est synonyme de cible plus importante.

Pourquoi WordPress ne peut pas se contenter de réparer

L'architecture des plugins est si profondément ancrée dans le fonctionnement de WordPress qu'elle ne peut être modifiée sans rompre la compatibilité ascendante avec des dizaines de milliers de plugins existants. Chaque plugin suppose un accès complet à la base de données. Supprimer cet accès signifierait que la plupart des plugins cesseraient de fonctionner.

WordPress aborde donc la sécurité par d'autres moyens : mises à jour régulières, plugins de sécurité (comme Patchstack), règles de pare-feu, principes de permissions minimales au niveau du rôle de l'utilisateur. Tout cela est utile, mais ne s'attaque pas à la cause première : l'architecture fait implicitement confiance à tous les plugins.

À cela s'ajoute le problème des plugins abandonnés. En 2024, 1 614 plugins et modèles vulnérables ont été retirés de WordPress.org grâce à des chercheurs en sécurité. Mais beaucoup d'entre eux restent installés sur des sites réels.

EmDash : une approche différente de la sécurité des plugins

En avril 2026, Cloudflare a présenté EmDash, un système de gestion de contenu (CMS) open-source qu'il qualifie de „successeur spirituel de WordPress“. Il en est à la version 0.1.0 - early developer. bêta conçu principalement pour les tests et le développement. Mais son architecture de sécurité mérite qu'on s'y attarde, même à ce stade.

Un bac à sable au lieu d'un accès complet

EmDash résout le principal problème architectural de WordPress : les plugins fonctionnent dans un environnement isolé (sandbox) et doivent déclarer à l'avance ce à quoi ils ont besoin d'accéder. Le plugin d'envoi d'e-mails obtient les autorisations „email:send“ et „read:content“, rien de plus. Il ne peut pas lire la base de données des utilisateurs, accéder aux données de paiement ou modifier le contenu d'autres plugins.

Sur Cloudflare Workers, chaque plugin fonctionne dans son propre environnement isolé V8. Même si un plugin est compromis, sa portée est limitée aux opérations explicitement autorisées. Un formulaire de contact compromis ne peut pas donner accès à l'ensemble du site.

Le modèle de sécurité complet d'EmDash est étroitement lié à l'architecture des travailleurs de Cloudflare et à leur modèle d'isolation. Pour les déploiements non-Cloudflare, il est conseillé de vérifier quelles garanties de sécurité sont maintenues dans la pratique.

Authentification sans mot de passe

Par défaut, WordPress utilise une connexion classique par nom d'utilisateur et mot de passe. Les attaques par force brute sur la page de connexion sont l'un des vecteurs d'attaque les plus courants.

EmDash ne prend pas du tout en charge les mots de passe. L'authentification par défaut utilise des passkeys (clés cryptographiques liées à l'appareil) et est conçue pour être enfichable - des fournisseurs d'identité externes peuvent être connectés. Aucun mot de passe ne peut être deviné, volé dans la base de données ou utilisé à mauvais escient à la suite d'une fuite provenant d'un autre service.

Licences et isolation du code

EmDash est entièrement écrit en TypeScript et utilise la licence MIT. Pour des raisons de sécurité, il est important que les plugins ne partagent aucun code avec EmDash - ils fonctionnent indépendamment. Cela signifie que Vulnérabilité dans le plugin ne peut pas utiliser l'API interne du noyau de la manière dont l'architecture de WordPress le permet.

Ce qu'EmDash n'est pas encore

Il est important de préciser ce que EmDash ne représente pas dans sa forme actuelle :

• Ce n'est pas un produit fini. Cloudflare indique qu'il s'agit d'une version v0.1.0 preview / early developer beta - il s'agit d'une version précoce destinée principalement aux tests et au développement.
• Il n'a pas Écosystème. WordPress propose des dizaines de milliers de plugins et de modèles. EmDash dispose de plusieurs démonstrations officielles.
• Le bac à sable dépend de la plateforme. L'isolation complète des plugins est fournie avec Cloudflare Workers. Pour les autres environnements, l'étendue des garanties de sécurité n'est pas clairement documentée.
• La mise en place est plus compliquée. Il faut travailler avec le dépôt GitHub et configurer la base de données - ce qui est loin de l'installation en cinq minutes de WordPress.

Ce qu'il faut retenir

EmDash n'est pas une raison pour quitter WordPress. Mais il y a lieu de réfléchir à la différence fondamentale entre les modèles de sécurité :

Il y a une leçon pratique pour les webmasters WordPress : si vous restez sur WordPress (et la plupart des gens ont de bonnes raisons d'y rester), faites attention à l'hygiène de sécurité des plugins :

• Minimiser le nombre de plugins. Chaque plugin est un vecteur d'attaque potentiel.
• Supprimer les plugins inutilisés et non mis à jour. Les plugins abandonnés constituent une menace silencieuse.
• Mise à jour continue. La plupart des attaques ciblent des vulnérabilités connues et déjà corrigées.
• Envisager une surveillance de la sécurité. Des outils tels que Patchstack permettent de déployer des règles de protection avant le correctif officiel.
• Utilisez l'authentification à deux facteurs. WordPress ne le propose pas par défaut, mais il existe des plugins fiables qui l'ajoutent.

EmDash montre à quoi peut ressembler un CMS conçu avec la sécurité comme principe architectural de base - et non comme une couche supplémentaire. Le fait qu'il devienne une alternative viable dépend du développement d'une communauté et d'un écosystème autour de lui. C'est un concept intéressant aujourd'hui. Mais un concept qui nomme correctement un problème que tous ceux qui gèrent un site WordPress devraient connaître.

Patchstack - State of WordPress Security 2025, Patchstack Mid-Year Report 2025, Cloudflare Blog, The Register, Search Engine Journal, The Repository