Magento 2 piraté : signes et marche à suivre

En bref

Ne supprimez rien dans l’urgence. Les fichiers, les comptes et les logs laissés par l’attaquant servent à comprendre par où il est entré.
Prévenez vite votre hébergeur ou votre agence, votre prestataire de paiement si des cartes ont pu être volées, et la CNIL si des données personnelles sont touchées : 72 heures au plus tard après la découverte, si possible.
Une restauration de sauvegarde ne suffit pas : si la faille reste ouverte, l’attaquant revient.
Après le nettoyage, changez tous les mots de passe, clés et jetons, appliquez les correctifs de sécurité et surveillez la boutique de près.

Sommaire

Les signes d’un Magento 2 piraté

Un piratage se voit rarement en vitrine. L’attaquant préfère rester discret : plus il reste longtemps, plus il récolte. Les signes sont souvent petits. Un seul ne prouve rien, mais deux ou trois ensemble méritent une vérification immédiate.

Ce que voient vos clients

Des redirections vers un autre site (jeux, pharmacie, fausse boutique), parfois seulement depuis Google ou seulement sur téléphone.
Un formulaire de paiement qui change d’aspect, une étape de paiement en plus, ou un paiement qui échoue puis réussit à la seconde tentative.
Des clients qui signalent une fraude sur leur carte après un achat chez vous.

Ce que vous voyez dans l’administration

Un compte administrateur que personne ne connaît, ou un compte existant passé administrateur complet. Voir notre guide : repérer un compte administrateur suspect.
Une intégration ou un accès à l’API que vous n’avez pas créé.
Des commandes anormales : beaucoup de petites commandes refusées, des paiements en échec en série, des clients créés en masse.
Un bloc de contenu ou un réglage d’en-tête modifié sans raison, avec un script que vous ne reconnaissez pas.

Ce que signalent les autres

Google affiche un avertissement dans ses résultats ou dans le navigateur. Le rapport « Problèmes de sécurité » de la Search Console indique alors ce qu’il a trouvé : contenu piraté, logiciel malveillant ou ingénierie sociale.
Votre hébergeur vous écrit : envoi de spam depuis le serveur, fichier malveillant détecté, charge anormale, compte suspendu.
Votre banque ou votre prestataire de paiement vous signale que votre boutique est un point commun entre plusieurs cartes fraudées. C’est souvent le signe d’un skimmer de carte bancaire.

Par où les pirates entrent en 2026 : StyleSmuggler, SessionReaper, PolyShell

La plupart des piratages récents de boutiques Magento passent par une faille connue, exploitée en masse dans les jours qui suivent sa publication. Si votre boutique n’a pas reçu le bon correctif à temps, c’est la première piste à vérifier. Voici les trois failles les plus exploitées cette année, avec les traces à chercher (situation au 26 octobre 2026).

StyleSmuggler (APSB26-146, CVE-2026-75650)

Ce qu’elle permet : à un attaquant sans compte d’exécuter du code sur le serveur, en passant par l’API GraphQL. Adobe lui donne la note la plus grave (10 sur 10). Elle est exploitée depuis début septembre 2026 ; Adobe a publié un correctif d’urgence le 7 septembre.
Versions concernées : Magento 2.4.4 à 2.4.9, jusqu’aux versions d’août 2026 comprises. Aucune version de Magento ne contient encore la correction : il faut appliquer le correctif isolé VULN-39341. Le correctif mensuel d’octobre (APSB26-153) ne le remplace pas : Adobe demande d’appliquer les deux.
Les traces : dans les logs du serveur web, des requêtes contenant styles[generatorClass] ou styles[first] ; dans var/log/exception.log, des erreurs Map file provided does not exist ou Type Error occurred when creating object: Aws\S3\S3Client.
Après une exploitation : l’attaquant a pu lire la clé de chiffrement. Adobe demande de la changer, ainsi que tous les accès (voir les mots de passe, clés et jetons à changer).

SessionReaper (APSB25-88, CVE-2025-54236)

Ce qu’elle permet : de prendre le contrôle de comptes clients par l’API REST et, selon la configuration, d’exécuter du code.
Versions corrigées : 2.4.8-p3, 2.4.7-p8, 2.4.6-p13, 2.4.5-p15 et 2.4.4-p16 (octobre 2025), ou le correctif isolé VULN-32437. Une boutique restée sur une version plus ancienne reste exposée.
Les traces : des fichiers PHP déposés dans pub/media, qui ne devrait contenir que des images et des documents.

PolyShell

Ce qu’elle permet : de déposer un fichier sans compte, par les options personnalisées d’un panier. Un fichier .phtml ou .phar déposé dans pub/media/custom_options/ peut ensuite être exécuté.
Versions concernées : révélée par Sansec en mars 2026, elle n’était alors corrigée que dans la branche 2.4.9. Sur une version plus ancienne, interdisez l’exécution de PHP dans pub/media au niveau du serveur web, et vérifiez avec la personne qui gère la boutique où en sont les correctifs pour votre version.
Les traces : de nombreux envois vers les paniers invités (guest-carts) depuis une même adresse, des fichiers .phtml ou .phar dans pub/media, un fichier accesson.php dans un dossier d’images, un script inconnu dans un bloc ou une page CMS.

Pour savoir si votre boutique est à jour, voir aussi les correctifs de sécurité Adobe pour Magento.

Magento piraté : ce qu’il ne faut pas faire dans les premières heures

Le premier réflexe est souvent de tout effacer pour que le problème disparaisse. C’est la pire chose à faire.

Ne supprimez ni fichiers, ni comptes, ni logs. Ce sont les preuves. Elles disent par où l’attaquant est entré, ce qu’il a pris et depuis quand. Sans elles, impossible de fermer la bonne porte, ni de répondre à votre banque, à la CNIL ou à votre assureur.
Ne restaurez pas une sauvegarde sans comprendre. Si la faille est toujours là, l’attaquant revient. Et une sauvegarde peut déjà contenir sa porte dérobée.
N’éteignez pas le serveur. Isolez-le si besoin, mais laissez-le allumé : sa mémoire contient aussi des traces. Visa recommande de couper la machine du réseau sans l’éteindre, et Cybermalveillance.gouv.fr de la débrancher d’Internet.
Ne vous connectez pas à la machine compromise pour y changer des mots de passe, Visa le déconseille. Changez vite les mots de passe des comptes exposés, mais depuis un ordinateur sain. Le grand changement de tous les accès vient ensuite, une fois la porte refermée.
Ne restez pas seul. Faites intervenir quelqu’un qui connaît Magento.

Qui prévenir quand votre boutique Magento est piratée

Votre hébergeur ou votre agence, tout de suite. Ils ont accès au serveur, aux logs et aux sauvegardes. S’ils sont sous-traitants de vos données, le RGPD les oblige d’ailleurs à vous signaler toute violation dont ils ont connaissance.
Votre prestataire de paiement ou votre banque, si des cartes ont pu être volées. Le guide de Visa demande de prévenir la banque du commerçant (l’acquéreur) immédiatement, et de lui remettre un rapport d’incident sous trois jours ouvrés. Votre contrat peut fixer d’autres règles : relisez-le.
La CNIL, si des données personnelles sont touchées : noms, adresses, e-mails, mots de passe des clients, cartes bancaires. Vous êtes responsable de traitement. Le RGPD vous demande de notifier la violation dans les meilleurs délais et, si possible, 72 heures au plus tard après en avoir pris connaissance, sauf si elle n’entraîne pas de risque pour les personnes. Si vous n’avez pas encore toutes les informations, la CNIL accepte une notification en deux temps.
Vos clients, si le risque pour eux est élevé (cartes bancaires, mots de passe). Le RGPD l’exige dans les meilleurs délais, sauf exceptions prévues par l’article 34.
La police ou la gendarmerie. Cybermalveillance.gouv.fr conseille de porter plainte avant de réinstaller quoi que ce soit, au commissariat, à la gendarmerie ou par écrit au procureur de la République.
Votre assureur, si vous avez une garantie qui couvre les attaques informatiques.

Dans tous les cas, notez la violation dans votre documentation interne : les faits, leurs effets et les mesures prises. Le RGPD l’impose même quand vous ne notifiez pas la CNIL.

Message à votre hébergeur ou à votre agence

Bonjour,

Nous pensons que notre boutique Magento a été piratée : [décrivez ce que vous avez vu, par exemple un administrateur inconnu, une redirection, une alerte de la banque].

Pouvez-vous, en urgence :

conserver une copie des logs du serveur web, de PHP et de Magento (var/log), sans rien supprimer ;
nous dire quelles sauvegardes existent et à quelles dates ;
nous indiquer si vous voyez une activité anormale sur le serveur ;
ne rien nettoyer ni restaurer avant que nous ayons compris l’origine de l’intrusion.

Merci de nous répondre au plus vite.

Vous gérez le serveur : premières vérifications sur un Magento 2 piraté

Ces commandes ne modifient rien sur le site. Elles servent à garder les preuves et à mesurer l’étendue de l’intrusion. Remplacez /var/www/boutique par le dossier de votre Magento.

Mettez les logs à l’abri avant qu’ils ne tournent. Adaptez les dossiers à votre serveur web, puis copiez l’archive hors du serveur :

Terminal

sudo tar --ignore-failed-read -czf /root/preuves-$(date +%F).tar.gz /var/log/nginx /var/log/apache2 /var/www/boutique/var/log
Cherchez des fichiers PHP dans pub/media. Ce dossier ne contient que des images et des documents. Un fichier PHP n’a rien à y faire :

Terminal

find /var/www/boutique/pub/media -type f $ -name '*.php' -o -name '*.phtml' -o -name '*.phar' $ -print
Listez les fichiers modifiés ces sept derniers jours, hors des dossiers que Magento réécrit lui-même :

Terminal

find /var/www/boutique $ -path /var/www/boutique/var -o -path /var/www/boutique/generated -o -path /var/www/boutique/pub/static -o -path /var/www/boutique/pub/media $ -prune -o -type f -mtime -7 -print

Une date de fichier se falsifie facilement. Une liste vide ne prouve donc rien.
Si le code est versionné avec Git, comparez-le au dépôt :

Terminal, depuis le dossier de Magento

git status --short
Regardez les tâches planifiées de l’utilisateur du site et les clés SSH autorisées. Un attaquant s’en sert pour revenir :

Terminal

Tâches planifiées de l'utilisateur du site sudo crontab -u www-data -l Clés SSH autorisées sur le serveur sudo find /root /home /var/www -name authorized_keys -print
Dans la base, listez les comptes administrateurs et les intégrations. Les requêtes sont dans notre article sur les comptes administrateurs suspects. Pour les scripts injectés dans les blocs CMS et la configuration, voir l’article sur les skimmers.

Pour les développeurs

Ce que recommande Adobe. La page d’Adobe « Best practices to respond to a security incident » demande notamment : auditer les comptes administrateurs, conserver les logs, comparer le code de production au dépôt Git, réinstaller les fichiers depuis une source saine, relire les champs HTML de l’en-tête et du pied de page à tous les niveaux (site, vue magasin), et réinitialiser tous les accès : base de données, fichiers, paiement, transport, intégrations et clés d’API.

Reprendre la main sur un Magento 2 piraté : avec ou sans sauvegarde saine

Une fois l’entrée de l’attaquant comprise, deux cas se présentent.

Vous avez une sauvegarde saine

Une sauvegarde est saine si elle date d’avant l’intrusion. Seule l’enquête donne cette date : c’est une raison de plus pour garder les traces.

Le code se restaure sans regret depuis la sauvegarde ou, mieux, depuis le dépôt Git et Composer.
La base de données est plus délicate : la restaurer efface les commandes et les clients enregistrés depuis. On préfère souvent la nettoyer à la main (comptes, intégrations, blocs, configuration), puis comparer avec la sauvegarde.
Appliquez ensuite les correctifs de sécurité avant de rouvrir la boutique. Sinon, la même faille sert une seconde fois.

Vous n’avez pas de sauvegarde saine

Il faut nettoyer. Adobe recommande de supprimer les fichiers inutiles, de réinstaller ceux dont la boutique a besoin depuis une source saine, de mettre en quarantaine le code suspect et de redéployer tout le code. Concrètement :

le cœur de Magento et les extensions sont réinstallés depuis Composer ;
le code propre à la boutique (thème, modules maison) est comparé ligne à ligne à son dépôt ou relu ;
la base est passée en revue : comptes administrateurs, intégrations, blocs et pages CMS, configuration HTML, adresses de la boutique.

Quand repartir d’un serveur neuf

Nettoyer le dossier de Magento ne suffit pas toujours. Si l’attaquant a pu exécuter des commandes sur le serveur, il a pu laisser des traces hors de la boutique : une tâche planifiée, une clé SSH, un compte système, un programme modifié, un fichier dans un autre site hébergé sur la même machine. Personne ne peut alors garantir que tout a été retiré.

Repartez d’un serveur neuf, installé de zéro, quand l’un de ces cas se présente :

l’attaquant a obtenu un accès au serveur lui-même (ligne de commande, SSH, compte de l’hébergeur), pas seulement à l’administration de Magento ;
des fichiers ont été modifiés en dehors du dossier de la boutique, ou des tâches planifiées, des clés SSH ou des comptes inconnus sont apparus ;
d’autres sites du même serveur sont touchés ;
l’enquête ne permet pas de dire jusqu’où l’attaquant est allé.

Sur le nouveau serveur, le code est redéployé depuis le dépôt Git et Composer, jamais copié depuis l’ancien. La base de données est importée après avoir été passée en revue, et tous les accès sont changés (voir ci-dessous). L’ancien serveur reste isolé, sans être effacé, le temps de l’enquête : il garde les preuves. Votre hébergeur peut fournir une nouvelle machine ; c’est souvent plus rapide et plus sûr qu’un long nettoyage.

Les mots de passe, clés et jetons à changer

Une fois la porte refermée, changez tout ce que l’attaquant a pu lire. Si vous le faites avant, il risque de voir passer les nouveaux accès :

les mots de passe de tous les comptes administrateurs, et supprimez les comptes inutiles ;
le mot de passe de la base de données, rangé dans app/etc/env.php ;
les accès SSH, SFTP et au panneau de l’hébergeur ;
la clé de chiffrement de Magento : Adobe demande de la changer dès qu’elle a pu être compromise, ce qui est le cas après une exploitation de StyleSmuggler (commande bin/magento encryption:key:change, seule méthode depuis Magento 2.4.8). Changer la clé ne suffit pas : les accès déjà lus doivent aussi être changés ;
les clés d’API du prestataire de paiement, du transporteur, de l’envoi d’e-mails ;
les intégrations : supprimez celles que vous ne connaissez pas, recréez les autres.

Après le nettoyage : éviter un nouveau piratage de Magento 2

Adobe le rappelle : beaucoup de sites sont de nouveau compromis dans les heures qui suivent un incident. Le PCI Security Standards Council fait le même constat pour les skimmers : si la faille n’est pas corrigée, ou si un morceau du code de l’attaquant reste en place, l’infection revient.

Appliquez les correctifs de sécurité d’Adobe et tenez-les à jour. Voir les correctifs de sécurité Adobe pour Magento.
Gardez l’authentification à deux facteurs de l’administration. Elle est activée par défaut depuis Magento 2.4.0, et Adobe déconseille fortement de la désactiver.
Surveillez l’intégrité du code : toute modification d’un fichier en dehors d’un déploiement doit vous être signalée.
Surveillez les comptes, les intégrations et les contenus : un nouvel administrateur ou un script ajouté dans un bloc doit déclencher une alerte.
Lisez les logs les jours suivants, et demandez à Google de réexaminer le site depuis la Search Console une fois toutes les pages nettoyées.
Faites le point à froid : notre audit de sécurité Magento 2 et notre guide pour sécuriser Magento 2 listent les réglages à revoir.

Tocsin24 repère les traces d’un piratage, pas seulement la panne

Tocsin24 relève votre boutique Magento toutes les heures par défaut et vous alerte par e-mail, notification ou SMS. Il compare les fichiers sensibles de Magento à la version officielle installée, signale un fichier PHP déposé dans pub/media, un fichier modifié hors déploiement ou modifié en cachant la modification. Il signale aussi un nouveau compte administrateur, une intégration inconnue, un bloc CMS ou un réglage d’en-tête qui contient un script, et une adresse de boutique changée. Chaque incident a sa fiche : les éléments concernés, l’historique et les preuves.

Tocsin24 n’est ni un pare-feu ni un nettoyage automatique : il signale et il explique. L’intervention reste humaine, avec l’intervention après compromission.

Essayer gratuitement Voir la surveillance Magento 2

Critique Ouvert #214

Fichier officiel différent de la version officielle

Sécurité · détecté le 22 octobre 2026 à 03:29 · 1 occurrence

Traiter l'incident

Fichiers concernés1 Relevé du 22 octobre 2026 à 03:29

Fichiers sensibles de Magento dont l'empreinte n'est ni celle de la version officielle installée, ni celle d'un patch officiel. Sous chaque fichier, la commande qui le compare à sa version officielle (dépôt public d'Adobe), à lancer à la racine de la boutique : les lignes « > » sont celles de la boutique ; un correctif Adobe appliqué apparaît aussi.

Fichier et commande de comparaison	Changement
pub/index.php curl -s 'https://raw.githubusercontent.com/magento/magento2/2.4.8-p2/pub/index.php' \| diff - 'pub/index.php'	MModifié

« Légitime » valide tout le lot.

Preuve de chaque passage dans « Historique et preuves ».

Référentiel

Ce qui est connu et validé sur l'instance : domaines, comptes, intégrations, contenus, fichiers. Tout écart est à valider.

Domaines 2
Comptes administrateur 3 1
Intégrations 2
Tokens API 3
Blocs CMS 18
Pages CMS 9
Configuration HTML 4
Fichiers inattendus dans media 0
Fichiers de code 68412

Comptes administrateur

Dernier rapprochement : 23 octobre 2026 à 09:00. Cochez les éléments que vous reconnaissez comme légitimes. Tout élément « à valider » est un écart ; un acquittement est daté et signé, et peut être révoqué.

À valider

support2

7 vu 23 octobre 2026 à 09:00

username

support2

email

support2@example.net

firstname

Support

lastname

Technique

role

Administrators

is_active

true

Légitime Non légitime
Légitime

cdurand

3 vu 23 octobre 2026 à 09:00
Légitime

direction

1 vu 23 octobre 2026 à 09:00

Écrans de l’application avec des valeurs d’exemple.

Questions fréquentes

Comment savoir si mon site Magento est piraté ?

Cherchez plusieurs signes ensemble : un compte administrateur inconnu, une intégration que vous n’avez pas créée, une redirection vers un autre site, un avertissement de Google, une alerte de votre banque ou de votre hébergeur. Un seul signe ne suffit pas à conclure, mais il justifie une vérification par la personne qui gère le serveur.

Ma boutique Magento est-elle concernée par StyleSmuggler (APSB26-146) ?

Oui, si elle tourne en Magento 2.4.4 à 2.4.9 sans le correctif isolé VULN-39341 : au 26 octobre 2026, aucune version de Magento ne contient encore la correction, pas même le correctif d’octobre (APSB26-153). Demandez à la personne qui gère la boutique de vérifier que VULN-39341 est appliqué, puis de chercher les traces d’exploitation dans les logs. Si la boutique a été exploitée, changez la clé de chiffrement et tous les accès.

Faut-il prévenir la CNIL si ma boutique Magento est piratée ?

Oui, si des données personnelles ont pu être lues ou volées et que cela crée un risque pour vos clients. Le RGPD demande de notifier la CNIL dans les meilleurs délais, si possible sous 72 heures après la découverte. Dans tous les cas, vous devez documenter la violation en interne.

Puis-je simplement restaurer une sauvegarde ?

Pas sans savoir comment l’attaquant est entré. La faille reste ouverte après la restauration, et la sauvegarde contient peut-être déjà sa porte dérobée. Restaurer la base efface aussi les commandes passées depuis. Comprenez d’abord, restaurez ensuite, puis appliquez les correctifs.

Faut-il fermer la boutique pendant le nettoyage ?

Si des cartes bancaires ou des données de clients sont en train d’être volées, oui, le temps de couper la fuite. Sinon, la boutique peut souvent rester ouverte pendant l’enquête. Décidez avec la personne qui intervient.

Pourquoi mon site Magento est-il de nouveau piraté après le nettoyage ?

Parce que la porte d’entrée est restée ouverte, ou qu’un élément de l’attaquant a survécu : un compte, une intégration, une tâche planifiée, une clé SSH, un fichier caché. Il faut corriger la faille, changer tous les accès et surveiller la boutique de près les semaines suivantes. Si l’attaquant a eu la main sur le serveur lui-même, le plus sûr est de repartir d’un serveur neuf.

Cédric Michel

Cédric développe des boutiques Magento depuis 18 ans et détient la certification Adobe Commerce Developer Expert. Il a créé Tocsin24 pour surveiller la sécurité et la santé des boutiques Magento 2 et des sites WordPress.

Adobe Commerce Developer Expert
Vérifier la certification sur le site d’Adobe

Magento 2 piraté : les signes qui doivent alerter et la marche à suivre