En bref : si votre boutique en ligne est piratée ou fonctionne sur une version de PHP non corrigée, trois enjeux sont en cause en même temps : les données clients, le tunnel de commande et votre chiffre d'affaires. Placez la boutique en mode maintenance de manière contrôlée, sauvegardez les journaux à partir du 20 octobre 2026 et déterminez qui met PHP à jour et le redémarre sur votre serveur.
Ce qui est en jeu dans une boutique en ligne
Une boutique est plus qu'un site web. Elle gère des comptes clients avec des empreintes de mots de passe, des adresses de livraison et de facturation, des historiques de commandes, des bons d'achat et souvent aussi des interfaces avec la gestion des stocks, les transporteurs et les places de marché. Quiconque peut exécuter du code sur le serveur accède en règle générale à la base de données et aux clés d'API qui y sont enregistrées.
Les données de cartes se trouvent le plus souvent non pas chez vous, mais chez le prestataire de paiement. Cela ne rassure qu'en partie : un attaquant peut introduire dans le processus de commande du JavaScript qui lit les saisies dans le navigateur. De tels scripts de skimming passent à peine inaperçus dans l'exploitation de la boutique, car les commandes aboutissent tout à fait normalement.
À cela s'ajoutent les interfaces. Une boutique qui transmet les commandes à la gestion des stocks, aux transporteurs et aux places de marché enregistre en général les clés d'accès correspondantes dans des fichiers de configuration sur le serveur. Quiconque les copie peut, au nom du commerçant, générer des étiquettes d'expédition, modifier les stocks ou détourner des comptes de places de marché.
Systèmes de boutique courants et pourquoi PHP2Shell les touche
Les systèmes de boutique répandus chez les PME européennes fonctionnent sur PHP : Shopware 6, WooCommerce, Magento, OXID, PrestaShop et de nombreuses anciennes installations Shopware 5. PHP2Shell (CVE-2026-109618 et CVE-2026-109619, CVSS 9.2 chacune) se trouve dans PHP lui-même. Les attaquants n'ont besoin ni d'un compte client ni d'un accès administrateur.
Pour les commerçants, cela signifie : la toute dernière mise à jour de la boutique ne protège pas. Ce qui compte, c'est que PHP sur le serveur soit en 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou que l'hébergeur ait appliqué un backport, et que tous les processus PHP aient ensuite été redémarrés. Pour les anciennes boutiques sous PHP 8.1 ou antérieur, le projet PHP ne fournit plus de mises à jour officielles. Dans ce cas, outre l'urgence, une migration s'impose, que vous ne souhaitez pas réaliser sous la pression du temps en pleine saison.
Boutique en ligne piratée : ce qu'un incident signifie concrètement
Une boutique compromise cause des dommages à plusieurs niveaux, qui s'aggravent mutuellement :
- Chiffre d'affaires : chaque heure de mode maintenance coûte des commandes. Une boutique qui continue de fonctionner à l'insu de tous peut toutefois coûter nettement plus cher.
- Données clients : les adresses et commandes dérobées servent à des e-mails d'hameçonnage ciblés qui paraissent authentiques parce qu'ils citent de vraies commandes.
- Visibilité : si Google détecte du code malveillant, un avertissement apparaît dans les résultats de recherche. Pour savoir comment le faire disparaître, consultez le guide Supprimer l'avertissement de Google.
- Partenaires : les prestataires de paiement et les places de marché ont leurs propres règles en cas d'incident de sécurité. Qui signale trop tard risque des ennuis lors du règlement.
Qui est responsable : agence, hébergeur ou commerçant ?
Dans de nombreuses boutiques, la question de PHP tombe entre deux chaises. L'agence a construit la boutique et entretient les extensions, l'hébergeur exploite le serveur, et le commerçant part du principe que l'un des deux s'en occupe. Avec un hébergement géré, c'est le plus souvent l'hébergeur qui applique les correctifs ; avec un serveur virtuel propre, personne ne le fait automatiquement.
| Tâche | Généralement responsable | À vérifier |
|---|---|---|
| Mettre à jour le paquet PHP | Hébergeur ou responsable du serveur | Confirmation écrite avec l'état des paquets |
| Redémarrer les processus PHP | Celui qui administre le serveur | Heure du redémarrage |
| Boutique et extensions | Agence | Contrat de maintenance et accès |
| Informer le prestataire de paiement | Commerçant | Obligations contractuelles de notification |
Un correctif PHP ne prouve pas que rien ne s'est produit auparavant. Si la boutique a été attaquée entre le 17 octobre et le moment du correctif, du code introduit peut continuer à s'exécuter. Faites-le vérifier avant de donner le feu vert.
Les premières heures : l'ordre à suivre pour les commerçants
- Placer la boutique en mode maintenance ou, si ce n'est pas possible, la déconnecter temporairement du réseau.
- Sauvegarder les journaux du serveur web, de PHP et de la boutique à partir du 20 octobre 2026, avant que la rotation ne les supprime.
- Faire confirmer par écrit par l'hébergeur l'état des paquets PHP et le redémarrage.
- Renouveler les mots de passe administrateur, les clés d'API de paiement, d'expédition et de places de marché ainsi que les accès à la base de données, et ce seulement après le nettoyage.
- Vérifier le tunnel de commande, les extensions de paiement et les scripts intégrés à la recherche de modifications.
S'il existe des indices d'une fuite de données, le délai de 72 heures du RGPD court. L'évaluation juridique, vous la faites avec votre délégué à la protection des données et, le cas échéant, votre avocat.
Comment PHP SOS aide-t-il concrètement ?
- Nous vérifions à distance l'état réel des paquets PHP, le mode d'exécution (par exemple mod_php ou PHP-FPM) et si tous les workers ont été redémarrés.
- Nous examinons les fichiers de la boutique, la base de données et le tunnel de commande à la recherche de webshells, de code de skimming et de nouveaux comptes administrateur, et nous supprimons les logiciels malveillants découverts.
- Nous nous coordonnons avec votre agence et votre hébergeur afin que la maintenance de la boutique et l'exploitation du serveur ne se croisent pas sans se rencontrer.
- Nous documentons les constats et les mesures de manière à ce que vous puissiez les présenter au prestataire de paiement, à l'assureur et au délégué à la protection des données.
- Ensuite, nous durcissons le serveur et, sur demande, nous assurons la surveillance continue.
Questions fréquentes
Dois-je déconnecter ma boutique du réseau à cause de PHP2Shell ?
Le BSI (office fédéral allemand de la sécurité des technologies de l'information) recommande de déconnecter temporairement les serveurs web du réseau lorsque la mise à jour de PHP n'est pas possible immédiatement. Pour une boutique, un mode maintenance avec une page d'information est souvent préférable à un message d'erreur. Dès que PHP est corrigé et que tous les processus ont été redémarrés, la boutique peut rouvrir.
Les données de cartes bancaires de ma boutique sont-elles menacées ?
Dans la plupart des boutiques, les données de cartes ne se trouvent pas sur le serveur de l'exploitant, mais chez le prestataire de paiement. Le danger vient toutefois d'un code manipulé dans le tunnel de commande, qui capte les saisies avant qu'elles n'atteignent le prestataire. C'est pourquoi le tunnel de commande fait partie de toute vérification après une attaque.
Suffit-il de mettre à jour Shopware ou WooCommerce ?
Non. PHP2Shell concerne PHP lui-même, pas le système de boutique. Une mise à jour de la boutique ne ferme pas la faille, et un correctif PHP ne supprime pas le code malveillant déjà introduit.
Qui dois-je informer après une fuite de données ?
En cas de données personnelles, une notification à l'autorité de protection des données dans un délai de 72 heures entre en ligne de compte et, selon le risque, également l'information des personnes concernées. S'y ajoutent des obligations contractuelles envers le prestataire de paiement et l'assureur. L'évaluation au cas par cas, vous la faites avec votre délégué à la protection des données et votre avocat.