11 334 failles WordPress en 2025
nouvelles vulnérabilités recensées, soit 42 % de plus qu’en 2024 ; 91 % dans les extensions, 9 % dans les thèmes (Patchstack, rapport 2026).
Patchstack, State of WordPress Security in 2026
Guide sécurité
Sécuriser un site WordPress ou PrestaShop : ce que la loi impose et ce qu’il faut exiger de son prestataire
Sécuriser un site WordPress ou une boutique PrestaShop, c’est avant tout maintenir à jour ce qui le compose (le CMS, ses extensions, PHP), limiter et protéger les accès d’administration, et disposer de sauvegardes réellement restaurables. Ce guide rassemble ce que disent la CNIL, l’ANSSI et Cybermalveillance.gouv.fr, les chiffres publics sur les failles, et les questions précises à poser à la personne qui gère votre site.
En 30 secondes
L’essentiel à retenir
Dès que votre site collecte des données personnelles (formulaire de contact, comptes clients, commandes), le RGPD vous oblige à le protéger par des mesures adaptées au risque, et à notifier la CNIL sous 72 heures en cas de violation de données. Cette responsabilité reste la vôtre, même si un prestataire gère le site.
Sur WordPress, la grande majorité des failles publiées concernent les extensions, pas le cœur du logiciel : 91 % des 11 334 vulnérabilités recensées par Patchstack en 2025. Sur PrestaShop, les attaques les plus graves de ces dernières années ont visé des modules vulnérables pour voler des numéros de carte. Dans les deux cas, les versions obsolètes de PHP ou du CMS aggravent le risque.
Les mesures qui comptent le plus sont connues et peu coûteuses : mises à jour régulières et testées, peu d’extensions, double authentification sur les comptes d’administration, sauvegardes selon la règle 3-2-1 avec un test de restauration, et un prestataire capable de dire précisément ce qu’il fait. C’est ce que vous pouvez vérifier dès aujourd’hui.
Chiffres clés
Ce que montrent les données publiques
-
-
46 % sans correctif
des vulnérabilités WordPress n’avaient pas encore de correctif au moment de leur divulgation publique en 2025 (Patchstack).
Patchstack, State of WordPress Security in 2026
-
504 000 demandes d’assistance
reçues par Cybermalveillance.gouv.fr en 2025, 20 % de plus qu’en 2024 ; les demandes liées aux violations de données ont plus que doublé.
Cybermalveillance.gouv.fr, rapport d’activité 2025
-
31/12/2026 fin de support de PHP 8.2
Date après laquelle PHP 8.2 ne recevra plus de correctif de sécurité ; PHP 8.1 n’en reçoit plus depuis le 31/12/2025 (php.net).
php.net, Supported Versions
Ce que la loi impose
La sécurité d’un site est une obligation, pas une option
L’article 32 du RGPD impose au responsable du traitement, c’est-à-dire l’entreprise qui édite le site, et à son sous-traitant de mettre en œuvre des mesures techniques et organisationnelles garantissant un niveau de sécurité adapté au risque. Le texte cite notamment la capacité à rétablir la disponibilité des données dans des délais appropriés après un incident, et la vérification régulière de l’efficacité des mesures prises. Un formulaire de contact, un espace client ou une boutique suffisent à entrer dans ce cadre.
En cas de violation de données personnelles, l’article 33 impose de notifier la CNIL dans les meilleurs délais et si possible dans les 72 heures, via son téléservice, et de documenter l’incident en interne dans tous les cas, même s’il n’est pas notifié. Si la violation présente un risque élevé pour les personnes, l’article 34 impose aussi de les informer. Confier son site à un prestataire ne transfère pas cette responsabilité : le contrat de sous-traitance (article 28) doit simplement organiser qui fait quoi.
Pour les sites marchands, les règles de sécurité des cartes bancaires s’ajoutent (voir plus bas). En revanche, la directive européenne NIS2, souvent citée, ne concerne pas la plupart des TPE : elle vise des secteurs précis et, sauf exceptions, des entreprises d’au moins 50 salariés ou 10 millions d’euros de chiffre d’affaires. Sa transposition en droit français était encore en discussion au Parlement en septembre 2026.
D’où viennent les piratages
Extensions, modules et versions obsolètes : les vraies portes d’entrée
WordPress fait tourner environ 40 % des sites web dans le monde selon W3Techs, ce qui en fait la cible la plus visée. Le cœur du logiciel est rarement en cause : dans le rapport 2026 de Patchstack, seules six vulnérabilités de faible priorité le concernent, contre 91 % pour les extensions et 9 % pour les thèmes. Le même rapport note que les failles les plus exploitées l’ont été massivement en quelques heures après leur publication, et que près de la moitié des vulnérabilités n’avaient pas de correctif au moment de leur divulgation. Autrement dit, chaque extension installée est un risque à suivre, et une extension abandonnée par son auteur est un risque permanent.
Sur PrestaShop, l’épisode de juillet 2022 reste une référence. PrestaShop a alerté sur une attaque combinant une injection SQL et une fonction de cache, qui permettait d’insérer un faux formulaire de paiement dans la page de commande pour voler les numéros de carte des clients. Les boutiques en 1.7.8.2 et au-delà n’étaient exposées que si elles utilisaient des modules vulnérables. Depuis 2020, la communauté Friends-Of-Presta publie une base d’avis de sécurité sur les modules et le cœur, régulièrement alimentée.
Le socle compte autant que les extensions. Un site qui tourne sur une version de PHP ou du CMS qui ne reçoit plus de correctifs reste exposé à des failles connues qui ne seront jamais corrigées. PrestaShop 1.6 n’est plus maintenu depuis juin 2019, et la branche 1.7 a cessé de l’être à la sortie de PrestaShop 9, en juin 2025. Le tableau suivant fait le point sur les versions à surveiller.
Versions à surveiller
PHP et PrestaShop : où en est le support de sécurité
État au 27 septembre 2026, d’après php.net et les annonces officielles du projet PrestaShop. Pour WordPress, le plus simple est de suivre la dernière version disponible et d’appliquer sans attendre les mises à jour de sécurité.
| Version | État aujourd’hui | Fin des correctifs de sécurité | Ce qu’il faut faire |
|---|---|---|---|
| PHP 8.0 et antérieures | Plus supportées | Entre 2018 et novembre 2023 | Migrer en priorité |
| PHP 8.1 | Plus supportée | 31 décembre 2025 | Migrer rapidement |
| PHP 8.2 | Correctifs de sécurité uniquement | 31 décembre 2026 | Planifier la migration dès maintenant |
| PHP 8.3 | Correctifs de sécurité uniquement | 31 décembre 2027 | Prévoir la migration en 2027 |
| PHP 8.4 et 8.5 | Support actif | Fin 2028 et fin 2029 | Versions recommandées |
| PrestaShop 1.6 | Plus maintenu | Juin 2019 | Migrer ou refondre |
| PrestaShop 1.7 | Plus maintenu | Sortie de PrestaShop 9 (juin 2025) | Migrer vers une version maintenue |
| PrestaShop 8.2 | Support étendu | Jusqu’à la sortie de PrestaShop 10 | Préparer le passage en 9 |
| PrestaShop 9.x | Version actuelle (9.1 depuis mars 2026) | Maintenue | Suivre les mises à jour mineures |
Sources : php.net (Supported Versions, Unsupported Branches) ; blog officiel du projet PrestaShop (fin de maintenance 1.6, support étendu 1.7.8 et 8.2, sorties de 9.0 et 9.1). Une version encore compatible avec votre hébergeur n’est pas pour autant maintenue.
Boutiques en ligne
E-commerce : protéger la page de paiement
Les boutiques qui acceptent la carte bancaire relèvent de la norme PCI DSS, établie par les réseaux de cartes. Depuis le 31 mars 2025, sa version 4.0.1 rend obligatoires deux exigences sur les scripts chargés par la page de paiement : ils doivent être autorisés, vérifiés dans leur intégrité et surveillés contre toute modification. C’est précisément la parade contre le type d’attaque subi par des boutiques PrestaShop en 2022.
Pour la plupart des petits marchands, la situation dépend de l’intégration du paiement. Si le client est redirigé vers la page de la banque ou du prestataire de paiement, l’essentiel du risque est porté par ce dernier. Si le formulaire de paiement est intégré dans votre site, même via une fenêtre fournie par le prestataire, vous devez depuis 2025 confirmer que votre site n’est pas exposé aux attaques par script, soit en appliquant vous-même ces protections, soit en obtenant la confirmation de votre prestataire de paiement. Demandez-la par écrit.
Les mesures essentielles
Dix mesures qui couvrent l’essentiel du risque
Mettre à jour régulièrement le CMS, les extensions ou modules, le thème et PHP, en testant avant d’appliquer sur le site en production. Sur WordPress, la mise à jour automatique des extensions existe depuis la version 5.5 mais reste désactivée par défaut : quelqu’un doit décider comment elle est gérée. Garder le moins d’extensions possible, comme le recommande la CNIL, et supprimer celles qui ne servent plus plutôt que de simplement les désactiver.
Protéger les accès : double authentification sur les comptes d’administration, recommandée par l’ANSSI et Cybermalveillance.gouv.fr ; mots de passe longs et uniques (au moins 12 caractères selon Cybermalveillance.gouv.fr), stockés dans un gestionnaire ; un compte nominatif par personne, et le retrait des accès des anciens salariés ou prestataires. Limiter l’accès aux interfaces d’administration aux seules personnes habilitées.
Sauvegarder selon la règle 3-2-1 que cite la CNIL : trois copies des données, sur deux supports différents, dont une hors ligne, et au moins une dans un lieu distinct. Tester réellement la restauration : une sauvegarde jamais restaurée n’est qu’une hypothèse. Chiffrer les échanges avec HTTPS sur tout le site, et configurer correctement les cookies de session. Enfin, surveiller : disponibilité, modifications de fichiers, journaux de connexion, et faire auditer le site périodiquement.
Votre prestataire
Les questions à poser à la personne qui gère votre site
Cybermalveillance.gouv.fr le résume simplement : assurez-vous des moyens mis en œuvre par votre prestataire pour protéger votre site. En pratique, un prestataire sérieux doit pouvoir répondre sans hésiter à ces questions. Quelles versions de PHP et du CMS tournent sur mon site, et quand seront-elles mises à jour ? À quel rythme appliquez-vous les mises à jour de sécurité, et les testez-vous avant ? Où sont stockées mes sauvegardes, combien de temps sont-elles conservées, et quand avez-vous testé une restauration pour la dernière fois ?
Puis sur les accès et les incidents. Qui a un accès administrateur au site et à l’hébergement, et la double authentification est-elle activée ? Comment êtes-vous alerté si le site est modifié ou tombe en panne, et dans quel délai intervenez-vous ? Qui prévient qui en cas de violation de données, sachant que la notification à la CNIL doit se faire sous 72 heures ? Ces réponses ont leur place dans le contrat, avec les engagements de sous-traitance prévus par l’article 28 du RGPD.
Enfin, gardez toujours la maîtrise de vos accès : nom de domaine, hébergement, administration du site et sauvegardes doivent pouvoir vous être remis à tout moment. C’est ce qui vous permet de changer de prestataire sans perdre votre site, un sujet que nous détaillons dans notre page sur le prestataire web injoignable. Chez DGS Création, plus de 300 sites et boutiques sont suivis en maintenance selon ces principes, avec un rapport d’activité qui dit ce qui a été fait.
Si c’est déjà arrivé
Votre site a déjà été piraté ?
Les premières heures comptent : conserver les preuves avant de nettoyer, prévenir l’hébergeur, déposer plainte, notifier la CNIL sous 72 heures si des données personnelles sont touchées, et, si vous êtes assuré contre le risque cyber, porter plainte dans les 72 heures pour pouvoir être indemnisé. Nous avons rassemblé ces étapes, dans l’ordre, sur notre page dédiée aux sites piratés.
FAQ
Questions fréquentes sur la sécurité d’un site
Les questions qui reviennent le plus souvent avant de lancer un projet digital, clarifier un besoin ou choisir le bon partenaire. Une autre question ? Écrivez-nous, nous répondons sous 24h ouvrées.
-
WordPress est-il moins sûr qu’un site sur mesure ?
Le cœur de WordPress est bien suivi et rarement en cause : l’essentiel des failles vient des extensions et des thèmes. Un WordPress sobre, avec peu d’extensions choisies et bien mises à jour, peut être très sûr. Un site sur mesure a une surface d’attaque plus réduite et moins ciblée par les attaques automatisées, mais il doit lui aussi être maintenu, notamment côté PHP et bibliothèques.
-
Mon site n’a qu’un formulaire de contact : le RGPD s’applique-t-il ?
Oui. Un formulaire de contact collecte des données personnelles (nom, e-mail, message), ce qui fait de vous un responsable de traitement soumis à l’obligation de sécurité de l’article 32 et, en cas de violation, à la notification de l’article 33. Les mesures attendues restent proportionnées au risque : pour un site vitrine, elles sont simples.
-
Faut-il activer les mises à jour automatiques ?
Cybermalveillance.gouv.fr recommande de configurer les mises à jour pour qu’elles s’installent automatiquement. Sur un site simple, c’est souvent raisonnable. Sur une boutique ou un site avec beaucoup d’extensions, une mise à jour peut casser une fonctionnalité : il est alors préférable de tester sur une copie du site avant d’appliquer, dans des délais courts pour les correctifs de sécurité.
-
Mon hébergeur ne protège-t-il pas déjà mon site ?
Il protège son infrastructure, pas le contenu de votre site. Un pare-feu d’hébergeur n’empêche pas l’exploitation d’une extension vulnérable : dans ses tests, Patchstack indique que les protections des hébergeurs évalués n’ont bloqué qu’une minorité des attaques visant WordPress. Les mises à jour et la gestion des accès restent de votre ressort ou de celui de votre prestataire.
-
Mon site PrestaShop est en version 1.7 : est-ce grave ?
La branche 1.7 ne reçoit plus de correctifs depuis la sortie de PrestaShop 9 en juin 2025, et elle tourne souvent sur des versions de PHP elles-mêmes en fin de support. Pour une boutique qui encaisse des paiements, c’est un risque réel. La migration vers une version maintenue se prépare, en vérifiant la compatibilité des modules et du thème.
-
La norme PCI DSS concerne-t-elle ma petite boutique ?
Oui, dès que vous acceptez la carte bancaire, mais son application dépend de l’intégration du paiement. En redirection complète vers la banque, le prestataire de paiement porte l’essentiel des exigences. Si le formulaire est intégré à votre site, vous devez depuis mars 2025 confirmer que votre site est protégé contre les attaques par script, ou obtenir cette confirmation de votre prestataire de paiement.
-
À quelle fréquence faut-il sauvegarder un site ?
Cela dépend de la fréquence à laquelle il change. Une boutique qui prend des commandes tous les jours a besoin de sauvegardes au moins quotidiennes de sa base de données ; un site vitrine peu modifié peut se contenter d’un rythme plus espacé. Dans tous les cas, la CNIL recommande la règle 3-2-1 avec une copie hors ligne, et la restauration doit être testée régulièrement.
Sources
Sources et références
Pages consultées le 27 septembre 2026. Ce guide est informatif et ne remplace pas un audit de votre site.
Pour aller plus loin
Prestations et ressources liées
Faire le point sur la sécurité de votre site
Nous commençons par un état des lieux : versions, extensions, accès, sauvegardes, hébergement. Vous recevez un diagnostic écrit avec les points à corriger, classés par priorité.