En bref : après PHP2Shell, la sécurité de WooCommerce dépend d'abord du PHP du serveur, et non du plugin de la boutique. Une boutique détient des données clients, des commandes et des accès à des prestataires de paiement ; le correctif PHP seul ne suffit donc pas. Contrôlez en plus le code du paiement, les clés API REST et les webhooks.
Ce que PHP2Shell signifie pour une boutique WooCommerce
WooCommerce est un plugin pour WordPress et fonctionne donc sur le même PHP. Les failles CVE-2026-109618 et CVE-2026-109619 permettent, selon l'équipe PHP, d'exécuter du code malveillant à distance sans authentification. Pour une boutique, c'est plus grave que pour un site vitrine, car l'enjeu est plus important :
- noms, adresses de livraison et de facturation, numéros de téléphone et adresses e-mail
- historique des commandes et comptes clients avec hachages de mots de passe
- clés API et secrets des connexions aux services de paiement, d'expédition et de comptabilité, stockés dans la base de données
- téléchargements de produits numériques dans le dossier
wp-content/uploads/woocommerce_uploads/
Avec les formulaires de paiement intégrés des prestataires, les données de carte ne se trouvent en général pas dans la boutique. Un attaquant ayant accès au serveur peut toutefois modifier le JavaScript du paiement de façon à lire les saisies avant l'envoi. Des conseils généraux pour les commerçants figurent sous Sécurité informatique pour les boutiques en ligne.
La sécurité de WooCommerce commence par la version de PHP
Sous WooCommerce > Statut, l'état du système affiche, dans la section consacrée à l'environnement serveur, la version de PHP avec laquelle la boutique fonctionne réellement. Les versions corrigées en amont sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Les hébergeurs intègrent toutefois souvent les correctifs sous forme de backport ; le numéro affiché reste alors ancien. Fiez-vous donc à la confirmation écrite de l'hébergeur et au redémarrage de tous les processus PHP.
Les versions de PHP prises en charge par votre version de WooCommerce se vérifient dans la configuration requise du fabricant sur woocommerce.com. Un passage à une version majeure plus récente de PHP devrait se faire dans un environnement de test, car des plugins de paiement peuvent sinon tomber en panne sans qu'on s'en aperçoive.
Où les attaquants s'en prennent aux boutiques WooCommerce
Outre les cachettes WordPress connues, il existe des endroits propres aux boutiques :
- Surcharges de modèles dans le thème : dossier
woocommerce/checkout/dans le thème actif. Les fichiers modifiés ici agissent directement sur la caisse et la confirmation de commande. - Plugins de paiement : fichiers modifiés dans
wp-content/plugins/du prestataire de paiement. - Clés API REST : sous WooCommerce > Réglages > Avancé > API REST. Une clé étrangère avec droits de lecture ou d'écriture est une porte dérobée sans fichier.
- Webhooks : sous Avancé > Webhooks. Un webhook inconnu peut envoyer chaque nouvelle commande à une adresse étrangère.
- Rôles : nouveaux comptes avec le rôle « Gestionnaire de boutique » ou « Administrateur ».
- Journaux :
wp-content/uploads/wc-logs/peut contenir des données personnelles et ne doit pas être accessible publiquement.
Contrôles sans danger en ligne de commande :
# Lister les administrateurs et les gestionnaires de boutique
wp user list --role=administrator
wp user list --role=shop_manager
# Afficher les fichiers PHP du thème modifiés depuis le 17/10/2026
find wp-content/themes -name "*.php" -newermt "2026-10-17"
Un correctif PHP ne supprime ni une clé API REST étrangère ni un webhook introduit. Les deux continuent de fonctionner après la mise à jour. Vérifiez donc activement les listes et, en cas de soupçon, renouvelez les clés API auprès de vos prestataires de paiement.
Extensions et mises à jour de la boutique : ce qu'elles apportent et ce qu'elles n'apportent pas
Une boutique WooCommerce typique utilise de nombreuses extensions : moyens de paiement, étiquettes d'expédition, génération de factures, connexions aux places de marché, plugins d'avis et de marketing. Chacune est un code supplémentaire avec ses propres failles et souvent ses propres accès à des services externes. Gardez la liste courte et supprimez les installations de test d'anciens moyens de paiement.
Une mise à jour de WooCommerce ou de WordPress comble des défauts connus dans ces composants. Elle ne répare pas PHP, ne supprime pas de fichiers étrangers en dehors du dossier des plugins et n'efface pas d'entrées de la base de données comme les clés API ou les webhooks. Pour savoir si quelque chose s'est déjà produit, consultez Suis-je déjà compromis ?.
Si la mise à jour de PHP est encore en attente chez l'hébergeur, un filtre placé en amont peut faire gagner du temps. Il ne remplace pas le correctif ; en savoir plus sous WAF et correctif virtuel.
Obligations en cas d'incident dans la boutique
Si des données personnelles de clients disparaissent, une notification à l'autorité de protection des données peut être nécessaire dans un délai de 72 heures. Il s'agit d'une information générale, pas d'un conseil juridique. Associez tôt votre délégué à la protection des données et lisez notre aperçu de l'obligation de notification RGPD. Respectez en outre les consignes de vos prestataires de paiement pour les incidents de sécurité.
Après chaque intervention, testez un parcours de commande complet avec tous les moyens de paiement que vous proposez. Soyez attentif aux étapes intermédiaires inhabituelles, aux champs de saisie supplémentaires ou aux redirections vers des domaines étrangers. Les outils de développement du navigateur montrent quels scripts sont chargés depuis quelles adresses ; des sources inconnues sur la page de caisse sont un signal d'alerte. Documentez le test avec la date et le résultat.
Comment PHP SOS aide-t-il concrètement ?
- Nous établissons avec votre hébergeur l'état du correctif PHP et faisons confirmer le redémarrage de tous les processus PHP.
- Nous sauvegardons les journaux, la base de données et les fichiers avant de modifier quoi que ce soit.
- Nous contrôlons les modèles de paiement, les plugins de paiement, les clés API REST, les webhooks et les rôles des utilisateurs.
- En cas de découvertes, nous nettoyons la boutique, renouvelons les accès avec vous et documentons le déroulement pour la protection des données et l'assurance.
Questions fréquentes
Les données de carte bancaire dans WooCommerce sont-elles menacées par PHP2Shell ?
Cela dépend de l'intégration du prestataire de paiement. Si les cartes sont saisies dans un formulaire du prestataire, elles ne se trouvent en général pas dans la boutique. Un attaquant ayant accès au serveur peut toutefois modifier le paiement de façon à intercepter les saisies au préalable.
Où vois-je la version de PHP dans WooCommerce ?
Sous WooCommerce > Statut, dans la section consacrée à l'environnement serveur. Le numéro indique la version avec laquelle la boutique fonctionne. Il ne permet pas de savoir si un backport a été appliqué ; l'hébergeur doit le confirmer.
Pourquoi devrais-je contrôler les webhooks WooCommerce ?
Lors d'événements tels que de nouvelles commandes, les webhooks envoient des données à une adresse enregistrée. Un webhook créé en cachette peut transmettre durablement des données de commande à des tiers, même après la correction de PHP.
Dois-je informer les prestataires de paiement en cas de soupçon ?
En cas de soupçon fondé, vous devriez renouveler les clés API auprès du prestataire et respecter ses consignes pour les incidents de sécurité. L'existence d'obligations de notification se clarifie avec votre délégué à la protection des données ou votre avocat.