Rapport Patchstack 2026 : 11 334 failles WordPress, et ce n’est que le début

On me dit souvent que WordPress est sûr. Que le core n’a que quelques failles par an. Que les mises à jour automatiques règlent le problème… Oui, et les hébergeurs bloquent les attaques. Et le Père Noël existe.

Le 25 février 2026, Patchstack a publié son rapport annuel "State of WordPress Security". Les chiffres sont sans appel : 11 334 nouvelles failles découvertes en 2025. +42% en un an. Et le 10 mars, WordPress nous a offert un cas d’école en sortant 3 patchs de sécurité en 30 heures. Dont un qui cassait les sites. De facto, si tu gères un WordPress en production, ce rapport devrait être ta lecture prioritaire ce mois-ci.

Bon. J’ai passé 14 ans à en voir des failles de sécurité sur des sites WordPress. J’ai co-créé WPS Hide Login (2 millions d’installations), WPS Limit Login, WPS Cleaner. Formateur WordPress depuis 2012, organisme certifié Qualiopi et pourtant je vis ces failles au quotidien sur les sites que je gère et ceux de mes stagiaires.

Alors oui, ce rapport fait froid dans le dos. Et NON, "mettre WordPress à jour" ne suffit plus!

11 334 failles en 2025 : que dit vraiment le rapport Patchstack ?

Le chiffre donne le vertige. En 2024, Patchstack avait répertorié 7 966 failles. En 2025, on passe à 11 334. C’est +42% en une seule année. Pour mettre ça en perspective, en 2023, on en comptait 5 948. La courbe ne fléchit pas, elle accélère. Chaque année, l’écosystème WordPress découvre plus de failles que l’année précédente, non pas parce que le code se dégrade, mais parce que la communauté sécurité scrute avec des outils de plus en plus performants. Résultat : des milliers de vulnérabilités qui existaient en silence remontent enfin à la surface. C’est une bonne nouvelle pour la transparence, une mauvaise pour ceux qui pensaient que "pas de faille signalée" voulait dire "pas de problème".

Où se trouvent ces failles ? La répartition est limpide : 91% dans les plugins, 9% dans les thèmes, et seulement 6 dans le core WordPress (toutes de basse priorité). Le core tient bon. Six failles en un an, toutes mineures. Mais le core, c’est le château. Les plugins, ce sont les 60 000 portes d’entrée que vous ajoutez vous-même.

Et parmi ces 11 334 failles, 1 966 sont classées "haute sévérité" : +113% par rapport à 2024. On ne parle pas de bugs cosmétiques. On parle de failles qui permettent de prendre le contrôle d’un site sans authentification.

Le chiffre qui m’a le plus marqué ? 4 124 failles (36% du total) ont nécessité un patch virtuel d’urgence via le système RapidMitigate de Patchstack. En clair : les correctifs officiels n’étaient pas prêts, et il fallait protéger les sites autrement.

Le paradoxe XSS : pourquoi les failles les plus fréquentes ne sont pas les plus dangereuses ?

Ça paraît évident, mais… non, la faille la plus répandue n’est pas celle qui fait le plus de dégâts. Le rapport Patchstack révèle un paradoxe que peu de guides sécurité expliquent clairement. Les vulnérabilités Cross-Site Scripting (XSS) représentent 47,7% de toutes les failles WordPress découvertes en 2025, soit près de la moitié. Pourtant, les XSS ne comptent que pour 1% des exploitations réelles en conditions de production. À l’inverse, les failles Broken Access Control ne représentent que 14% des failles découvertes, mais pèsent 57% des exploitations réelles. Autrement dit : les attaquants ne perdent pas leur temps avec les XSS. Ils ciblent les failles qui leur donnent un accès direct au site, sans passer par la case "convaincre un admin de cliquer sur un lien piégé".

La leçon ? Si tu dois prioriser ta sécurité, ne te focalise pas sur le nombre de failles. Regarde lesquelles sont exploitées. Un plugin avec une faille Broken Access Control non corrigée est infiniment plus dangereux qu’un plugin avec trois XSS documentées.

46% des failles n’ont aucun correctif au moment de la divulgation

Le modèle de sécurité WordPress repose sur un principe : quand une faille est divulguée publiquement, un correctif existe déjà. La réalité est tout autre.

Selon Patchstack, 46% des failles n’avaient aucun patch disponible au moment de la divulgation publique. Presque une sur deux. Laissez ça infuser un instant… Le problème, c’est que la divulgation publique déclenche la course. Dès qu’un CVE paraît, les scanners automatiques (bons et mauvais) se mettent en marche. Si le correctif n’est pas là, votre site est une cible ouverte, avec mode d’emploi publié sur internet.

Comment c’est possible ? Plusieurs raisons convergent :

• Des développeurs solo qui ne répondent pas aux signalements
• Des plugins abandonnés mais toujours installés sur des milliers de sites
• Des processus de divulgation responsable qui échouent (le développeur a 90 jours pour corriger, mais ne le fait pas)
• Des plugins premium vendus sur des marketplaces avec des cycles de mise à jour plus lents

Et les rapports hebdomadaires de SolidWP confirment la tendance : chaque semaine, ce sont 200 à 300 nouvelles failles répertoriées dans l’écosystème WordPress, dont un tiers environ sans aucun correctif disponible.

Ça vous parle ? Votre site utilise en moyenne 15 à 25 plugins. Statistiquement, au moins un d’entre eux a une faille non corrigée en ce moment. On ne sait jamais… et c’est bien le problème.

5 heures pour exploiter une faille : quelle est votre fenêtre de survie ?

Voici le chiffre le plus alarmant du rapport. La médiane d’exploitation des failles les plus ciblées tombe à 5 heures après la divulgation publique. Cinq heures. C’est le temps entre "la faille est publique" et "des bots scannent votre site pour l’exploiter". Décomposé : 20% des failles sont exploitées sous 6 heures. 45% sous 24 heures. 70% sous 7 jours. Si tu comptes faire tes mises à jour le week-end prochain… c’est déjà trop tard.

Et les pics saisonniers aggravent la situation. En novembre-décembre 2025, les uploads malveillants ont été multipliés par 3 par rapport au reste de l’année (source : Monarx). Les scripts uploader avaient déjà doublé en juin 2025. Les attaquants savent quand les équipes sont en vacances. Mon conseil : renforce ta surveillance pendant les fêtes et les ponts. C’est là que les dégâts arrivent.

Un exemple concret ? King Addons pour Elementor, CVE-2025-8489, score CVSS 9.8/10 (critique). Une faille d’escalade de privilèges permettant à n’importe qui de se créer un compte admin. Sans authentification. Le patch est sorti le 25 septembre 2025. L’exploitation de masse a commencé le 9 novembre. Wordfence a bloqué plus de 48 400 tentatives.

Autre cas récent : SureTriggers (CVE-2025-3102), un plugin d’automatisation avec 100 000+ installations. Faille d’authentification bypass, score CVSS 9.8. Le temps entre la divulgation publique et les premiers exploits automatisés ? 4 heures. Même pas le temps de finir une réunion Zoom. Et LiteSpeed Cache (5 millions d’installations) a cumulé 4 CVE entre 2024 et 2025, dont une qui a généré 58 952 attaques en 24 heures selon les données Wordfence. Quand tu as un plugin installé sur 5 millions de sites, chaque faille devient un événement de sécurité à l’échelle du web.

Imaginez le même scénario sur un plugin que vous utilisez. Le patch sort un mardi. Vous êtes en réunion. Votre site est compromis avant le déjeuner.

Quels sont les 4 malwares WordPress les plus dangereux en 2025 ?

Une fois le site compromis, que se passe-t-il ? Les attaquants ne se contentent plus de défigurer votre page d’accueil. En 2025, quatre familles de malware dominent l’écosystème WordPress, et elles sont bien plus sophistiquées qu’un simple script injecté dans le footer.

Parrot TDS est le plus répandu : 64% des injections de code malveillant détectées par Monarx en 2025 portent sa signature. TDS signifie "Traffic Distribution System" : le malware redirige vos visiteurs vers des pages de phishing ou de téléchargement piégé. Le plus pervers, c’est que Parrot TDS détecte les crawlers (Googlebot, Bingbot, et même les crawlers IA comme GPTBot) et leur sert une page propre. Vous ne voyez rien dans la Search Console, vos visiteurs réels prennent tout. Un malware invisible pour les moteurs de recherche mais dévastateur pour vos utilisateurs.

Japanese SEO spam (ou "pharma hack japonais") hijacke votre sitemap.xml et votre robots.txt pour injecter des milliers de pages en japonais vendant des médicaments ou des contrefacons. Votre site indexe soudainement 50 000 pages que vous n’avez jamais créées. Google vous pénalise, vos positions s’effondrent, et le nettoyage prend des semaines.

jgalls utilise un encodage hexadécimal et octal pour masquer son code source. Les scanners classiques ne le détectent pas parce que le code ne ressemble à rien de connu. Il faut un outil qui décode les couches d’obfuscation avant d’analyser. Bref. Si ton scanner de sécurité est basique, jgalls passe à travers.

Lock360 est le cauchemar des webmasters. Ce malware reste en mémoire résidente et se réinstalle automatiquement après chaque nettoyage. Tu supprimes les fichiers infectés, tu relances le site, et 3 minutes plus tard tout est de retour. La seule solution fiable : restaurer depuis un backup sain antérieur à l’infection, puis corriger la faille d’entrée avant de remettre en ligne.

Combien coûte réellement un hack WordPress ?

On l’oublie trop souvent, mais un site hacké ce n’est pas juste "un problème technique à régler". C’est une cascade de coûts qui s’empilent sur des mois. Le nettoyage technique d’un site WordPress compromis démarre à 3 000 $ pour un site simple et peut atteindre 1,24 million de dollars pour une entreprise qui subit une fuite de données combinée à une compromission de sa chaîne de paiement (source : IBM Cost of a Data Breach 2025). Le downtime moyen après un hack est de 3,2 jours. Trois jours sans site, sans ventes, sans formulaires de contact, sans visibilité. Et si Google vous blackliste pour malware, le recovery SEO prend de 6 à 12 mois. Vos positions chèrement acquises, parties en fumée.

Si tu hésites encore à investir 2 heures et quelques dizaines d’euros dans la sécurité de ton site, compare avec le coût d’un nettoyage. Le calcul est vite fait…

Le fiasco 6.9.2 → 6.9.4 : que s’est-il passé en 30 heures ?

10 mars 2026, 16h UTC. WordPress publie la version 6.9.2. Une mise à jour de sécurité majeure : 10 failles corrigées. Blind SSRF, XSS stocké, path traversal PclZip, XXE via getID3… le bulletin est chargé.

Cinq heures plus tard, 6.9.3 sort. Pourquoi ? Parce que 6.9.2 cassait le front-end de certains sites. Écran blanc. Certains thèmes utilisaient des "stringable objects" (objets PHP avec __toString()) au lieu de chaînes natives dans le filtre template_include. Un usage non documenté, certes, mais courant. Résultat : des milliers de sites en panne.

Le lendemain, 11 mars, 6.9.4 sort. Pourquoi cette fois ? Parce que 3 des 10 correctifs de sécurité de 6.9.2 n’avaient pas été complètement appliqués. Path traversal PclZip (CVE-2026-3907), XXE getID3 (CVE-2026-3908), bypass d’autorisation Notes (CVE-2026-3906) : il a fallu les re-corriger.

Trois releases en moins de 30 heures. Du jamais vu depuis la création de WordPress en 2003. Et pour ceux qui avaient activé les mises à jour automatiques, ça veut dire trois mises à jour subies en une journée, dont une qui plantait le site.

On l’oublie trop souvent, mais les mises à jour automatiques sont supposées rendre la vie plus simple. Pas la compliquer. De mon côté, mes sites n’ont pas été touchés : j’ai désactivé les mises à jour automatiques majeures, et je ne mets à jour que manuellement, quand je suis devant l’écran. Pas de panique le matin en ouvrant le navigateur…

Votre hébergeur vous protège-t-il vraiment ?

Patchstack a testé. Ils ont lancé des attaques réelles contre des hébergeurs WordPress et mesuré leur capacité à bloquer les exploits connus. Le résultat est… décevant. Le meilleur hébergeur testé (hors Patchstack lui-même) a bloqué 60.7% des attaques. Certains tombent sous les 17%. Et un hébergeur a obtenu un score de 0% de blocage. Zéro. Rien. Nada.

Et en moyenne ? Seulement 26% des attaques sont bloquées par les protections des hébergeurs. Quand on regarde les protections spécifiques à WordPress, ça tombe à 12%. Selon les tests de Patchstack en 2025, le meilleur hébergeur WordPress testé bloque 60,7% des attaques connues tandis que la moyenne du secteur tombe à 26%. Les protections spécifiques à WordPress (détection de failles dans les plugins, blocage des exploits ciblés) ne sont efficaces qu’à 12%. Un hébergeur fournit un serveur, une infrastructure réseau et un pare-feu générique, mais il ne connaît pas la logique applicative de WordPress ni les vulnérabilités spécifiques de chaque plugin installé sur votre site.

Autant dire les choses clairement : si ta stratégie de sécurité se résume à "mon hébergeur s’en occupe"… elle ne tient pas. Un hébergeur fournit un serveur, pas un bouclier.

Nota : les hébergeurs testés ne sont pas nommés publiquement dans le rapport. Je ne peux donc pas vous dire si O2switch (que j’utilise pour wpformation.com depuis 2025) fait partie du lot. Mais le constat est limpide : un hébergeur seul ne suffit pas.

Les plugins premium sont-ils plus sûrs que les gratuits ?

Instinctivement, on se dit qu’un plugin payant, développé par une équipe professionnelle, sera mieux sécurisé. C’est faux !

Patchstack a analysé 1 983 failles dans les plugins premium et freemium. Le ratio de failles activement exploitées (KEV) est 3 fois plus élevé dans les plugins premium que dans les gratuits. Et les zero-days premium (33) dépassent largement les zero-days gratuits (12). Prenez GiveWP, un plugin de dons très populaire : une faille RCE (exécution de code à distance) permettait à un attaquant de prendre le contrôle total du serveur. Ou FunnelKit Automations, où une faille permettait d’installer un plugin arbitraire sans aucune authentification. Un attaquant pouvait injecter une backdoor déguisée en plugin légitime.

Pourquoi ? Les plugins premium sont des cibles à haute valeur. Un plugin e-commerce premium installé sur 50 000 boutiques, c’est une mine d’or pour un attaquant. Et les cycles de mise à jour des marketplaces comme Envato sont souvent plus lents que ceux de wordpress.org.

Bref. Payer un plugin ne vous protège pas. Ce qui vous protège, c’est un développeur réactif et un processus de divulgation responsable. Vérifiez toujours la date de dernière mise à jour et le changelog avant d’acheter…

Que change le Cyber Resilience Act européen pour WordPress ?

Et après ? Ce n’est pas seulement une question technique, c’est aussi une question légale. Le règlement européen Cyber Resilience Act (CRA) entre en application en septembre 2026, et il va changer les règles du jeu pour tout l’écosystème WordPress. Toute entreprise qui commercialise un produit numérique dans l’UE (et ça inclut les plugins WordPress premium) devra signaler toute vulnérabilité activement exploitée à l’ENISA dans un délai de 24 heures. Pas 90 jours. Pas "quand on aura le temps". Vingt-quatre heures.

Le CRA impose aussi la mise en place d’un VDP (Vulnerability Disclosure Policy) obligatoire pour tout plugin commercial. En clair, chaque éditeur devra publier une procédure formelle de signalement des failles, et répondre dans des délais imposés. Les amendes ? Jusqu’à 15 millions d’euros ou 2,5% du chiffre d’affaires mondial. On est loin de l’amende symbolique.

Quel impact concret pour vous ? Si vous êtes freelance ou agence WordPress, le CRA vous oblige à documenter tous les composants logiciels de vos sites clients. Un inventaire de plugins (SBOM : Software Bill of Materials) avec leurs versions et leurs dépendances. Si un plugin que vous avez installé est compromis et que vous n’avez pas de traçabilité, vous êtes en défaut. Il vous faudra a minima une feuille de route sécurité documentée pour chaque projet client (source : WP Umbrella, législation UE).

L’IA est-elle en train de changer la donne en sécurité WordPress ?

"AI is increasingly capable of autonomously finding and exploiting vulnerabilities."

Oliver Sild, CEO de Patchstack

Oliver Sild, le CEO de Patchstack, le dit sans détour : l’intelligence artificielle est désormais capable de découvrir et d’exploiter des vulnérabilités de manière autonome. Ce n’est plus de la science-fiction. Les outils IA utilisés par les chercheurs en sécurité (et par Patchstack eux-mêmes) pour trouver les failles sont les mêmes types de modèles que ceux accessibles aux attaquants. La différence ? Les attaquants n’ont pas besoin de divulgation responsable. Ils trouvent, ils exploitent. La multiplication des failles découvertes en 2025 (+42%) reflète en partie cette réalité : les outils de détection automatique (y compris les LLM) remontèrent des vulnérabilités que l’audit humain aurait mis des mois à trouver.

Côté défense, l’IA accélère aussi les patchs virtuels. Patchstack utilise son système RapidMitigate pour générer des règles de protection en quelques heures là où un développeur humain mettrait des jours. C’est la course entre l’épée et le bouclier, version 2026. Et pour l’instant, l’épée a de l’avance…

Comment j’ai sécurisé wpformation.com : ma checklist post-rapport

Après avoir lu ce rapport, j’ai repassé en revue la sécurité de wpformation.com. Voici ma checklist, applicable à tout site WordPress :

1. Réduire la surface d’attaque. J’utilise 3 plugins actifs. Pas 25. Chaque plugin est un vecteur potentiel. Si tu n’as pas besoin d’un plugin, supprime-le. Pas "désactive". Supprime. Un plugin désactivé mais présent sur le serveur reste un vecteur d’attaque. Si un plugin n’a pas été mis à jour depuis 12 mois, remplace-le ou dégage-le.

2. Mises à jour majeures = staging d’abord. Je ne fais plus les mises à jour majeures directement en production. WordPress Playground ou un environnement de staging, puis production. Il vous faudra a minima 30 minutes pour tester correctement une mise à jour majeure.

3. Headers de sécurité. Content-Security-Policy, X-Frame-Options, Strict-Transport-Security. Mon mu-plugin les ajoute automatiquement. (Mon guide des en-têtes de sécurité)

4. Masquer la page de connexion. WPS Hide Login (que j’ai co-créé, 2M+ installations) élimine les attaques par force brute sur wp-login.php. C’est le premier geste, ça prend 30 secondes.

5. Limiter les tentatives. WPS Limit Login bloque les IP après X tentatives échouées.

6. Un WAF dédié. Wordfence ou Patchstack (qui fournit des patchs virtuels avant les correctifs officiels). En 2026, avec 5 heures de fenêtre d’exploitation, le patch virtuel n’est plus un luxe.

7. 2FA sur tous les comptes admin. Pas négociable. L’authentification à deux facteurs bloque 99% des accès non autorisés. (Mon guide 2FA)

8. Sauvegardes quotidiennes testées. Si tu n’as pas de backup, tu joues à la roulette russe. Une sauvegarde non testée, c’est pas une sauvegarde. Point. Teste ta restauration au moins une fois par mois.

9. Monitoring temps réel. Un outil qui vous alerte quand un fichier est modifié ou qu’un login suspect se produit. Wordfence le fait. Patchstack aussi. L’idée : savoir en minutes, pas en semaines.

10. Inventaire de composants (SBOM). Avec le CRA européen qui arrive en septembre, documentez chaque plugin, sa version, sa date de dernière mise à jour. Pour vos sites clients, c’est un minimum légal.

Faut-il activer les mises à jour automatiques après le fiasco 6.9.2 ?

La question qui fâche. Avant le 10 mars, j’aurais dit oui sans hésiter. Aujourd’hui… c’est plus nuancé.

Arguments pour : 5 heures de fenêtre d’exploitation. Si vous ne faites pas les mises à jour dans les heures qui suivent, votre site est exposé. Les auto-updates comblent ce gap.

Arguments contre : le fiasco 6.9.2 → 6.9.3 prouve qu’une mise à jour peut casser votre site. Si tu n’as pas de staging, pas de backup automatique, pas de monitoring, l’auto-update devient un risque en soi.

Mon conseil : active les mises à jour automatiques pour les mises à jour mineures de sécurité (c’est le cas par défaut dans WordPress). Pour les majeures, garde le contrôle. Et dans tous les cas, aie un backup quotidien qui fonctionne. Parce que le jour où une mise à jour casse quelque chose, c’est ton filet de sécurité. Mets à jour. Maintenant. Mais avec un filet. Pour creuser ce sujet, j’ai écrit un guide complet sur les mises à jour WordPress.

Et si tu veux vérifier la santé de ton installation, l’outil Santé du site de WordPress est un bon point de départ. Teste ton site avec cet outil, note ce qui cloche, et corrige dans l’ordre de sévérité.

Bonus : Veille de sécurité WordPress

Si tu veux aller plus loin sans alourdir ton WordPress, tu peux aussi utiliser notre outil de veille de sécurité WordPress gratuit qui t’alerte immédiatement de toute faille de sécurité sur tes plugins installés. Le concept : nous scannons ton site pour identifier tes plugins et ton thème, puis nous les surveillons chaque jour. Si une faille de sécurité est publiée sur l’un d’eux, tu reçois un email personnalisé avec la marche à suivre. Pas d’alerte générique. Uniquement ce qui te concerne.

Gratuit, simple et efficace ;)

Questions fréquentes sur la sécurité WordPress en 2026

Qu’est-ce que le rapport Patchstack 2026 ?

Le rapport Patchstack "State of WordPress Security" est une analyse annuelle des failles de sécurité dans l’écosystème WordPress. L’édition 2026 (publiée le 25 février 2026) couvre l’année 2025 et révèle 11 334 nouvelles failles, soit une augmentation de 42% par rapport à 2024. C’est la référence de l’industrie pour évaluer l’état de la sécurité WordPress.

Combien de failles WordPress ont été découvertes en 2025 ?

Patchstack a répertorié 11 334 nouvelles failles en 2025. La répartition : 91% dans les plugins, 9% dans les thèmes et seulement 6 dans le core WordPress (toutes de basse priorité). Parmi ces failles, 1 966 (17%) sont classées haute sévérité, en hausse de 113% par rapport à 2024.

Que s’est-il passé avec WordPress 6.9.2, 6.9.3 et 6.9.4 ?

Le 10 mars 2026, WordPress a publié 6.9.2 (10 failles corrigées). Cinq heures plus tard, 6.9.3 est sorti pour corriger un écran blanc causé par 6.9.2 sur certains thèmes. Le lendemain, 6.9.4 a été publié car 3 des 10 correctifs de 6.9.2 étaient incomplets (CVE-2026-3907, CVE-2026-3908, CVE-2026-3906). Trois releases de sécurité en moins de 30 heures.

Mon hébergeur protège-t-il suffisamment mon site WordPress ?

Selon les tests de Patchstack, le meilleur hébergeur testé bloque 60,7% des attaques WordPress. La moyenne tombe à 26% pour les protections générales et seulement 12% pour les protections spécifiques à WordPress. Un hébergeur fournit un serveur, pas un bouclier de sécurité complet. Il faut ajouter un WAF (Wordfence, Patchstack), des headers de sécurité et une stratégie de mises à jour.

Les plugins premium WordPress sont-ils plus sécurisés que les gratuits ?

Non. Le rapport Patchstack montre que le ratio de failles activement exploitées est 3 fois plus élevé dans les plugins premium que dans les gratuits. Les zero-days premium (33) dépassent aussi les zero-days gratuits (12). Un plugin payant n’est pas synonyme de plugin sécurisé. Ce qui compte, c’est la réactivité du développeur et la fréquence des mises à jour.

Comment savoir si mes plugins WordPress ont des failles connues ?

Consultez la base de données Patchstack (patchstack.com/database) qui répertorie les failles par plugin avec leur sévérité. Wordfence publie aussi des alertes hebdomadaires. Sur votre site, l’écran "Santé du site" (Outils > Santé du site) signale les plugins obsolètes et les mises à jour manquantes. Supprimez tout plugin qui n’a pas été mis à jour depuis plus de 12 mois.

WordPress est-il encore sûr en 2026 ?

Le core WordPress reste solide avec seulement 6 failles mineures en 2025. Le problème vient des plugins (91% des failles) et du délai de correction (46% sans patch à la divulgation). WordPress est sûr à condition de réduire sa surface d’attaque (moins de plugins), maintenir tout à jour rapidement, et ajouter un WAF. Sans ces mesures, c’est un pari risqué.

Qu’est-ce que le Cyber Resilience Act et quel impact sur WordPress ?

Le Cyber Resilience Act (CRA) est un règlement européen entrant en application en septembre 2026. Il impose aux éditeurs de plugins commerciaux un signalement des failles exploitées sous 24 heures à l’ENISA, une politique de divulgation (VDP) obligatoire, et un inventaire des composants logiciels (SBOM). Les amendes peuvent atteindre 15 millions d’euros ou 2,5% du CA mondial. Les agences WordPress devront documenter tous les composants de leurs sites clients.

Quels sont les malwares WordPress les plus courants en 2025 ?

Quatre familles dominent : Parrot TDS (64% des injections, redirige les visiteurs vers du phishing en masquant l’attaque aux crawlers), Japanese SEO spam (hijack du sitemap pour injecter des pages japonaises), jgalls (encodage hexadécimal anti-détection) et Lock360 (malware résident qui se réinstalle après nettoyage). La seule défense fiable contre Lock360 est une restauration complète depuis un backup sain.

Combien coûte la réparation d’un site WordPress hacké ?

Le nettoyage d’un site WordPress compromis démarre à 3 000 $ pour un site simple. Pour une entreprise avec fuite de données, le coût peut atteindre 1,24 million de dollars (source : IBM). Le downtime moyen est de 3,2 jours, et le recovery SEO après blacklisting Google prend 6 à 12 mois. 60% des PME victimes d’un cyberincident majeur ferment dans les 6 mois.

La sécurité WordPress en 2026 : ce qu’il faut retenir

Ce rapport Patchstack, je l’ai lu deux fois. La première avec l’oeil du technicien. La seconde avec une vraie inquiétude pour les 42,4% du web qui tournent sous WordPress (source : W3Techs, mars 2026) et dont une bonne partie ne fera jamais les mises à jour à temps.

La bonne nouvelle, c’est que 10 mesures suffisent à couvrir 95% des risques. La mauvaise, c’est que la plupart des sites n’en appliquent même pas la moitié…

Si vous ne retenez qu’une chose de cet article : 5 heures. C’est votre fenêtre. Pas la semaine prochaine. Pas demain. Cinq heures après la divulgation d’une faille, les bots sont déjà chez vous. Avec le CRA européen qui arrive, les malwares de plus en plus sophistiqués, et l’IA qui automatise la découverte de failles, 2026 sera l’année où la sécurité WordPress passe du "nice to have" au "condition de survie".

Bref. Prenez 2 à 3 heures pour blinder votre site. C’est le meilleur investissement que vous ferez cette semaine. Et si vous ne savez pas par où commencer, mon guide complet sécurité est là pour ça.