Intrusion sur une boutique Magento : retour d’expérience d’une remédiation en 4h

Maxime — Sat, 27 Jun 2026 06:00:00 +0000

Un vendredi soir, le propriétaire d’une boutique Magento reçoit un signalement inhabituel : des clients se plaignent de débits bancaires suspects après avoir commandé. Ce n’est pas un bug de caisse. Ce n’est pas une erreur de paiement. C’est une intrusion — un attaquant a compromis la boutique, déposé un skimmer JavaScript dans le processus de checkout, et collectait silencieusement les données bancaires depuis plusieurs semaines.

Voici le déroulement de cette intervention, de la détection à la remédiation complète, en moins de 4 heures.

Le contexte de l’intrusion

La boutique concernée tournait sur Magento 2.4.6 avec des mises à jour de sécurité partielles — le dernier patch de sécurité n’avait pas été appliqué depuis plusieurs mois. Le vecteur d’intrusion identifié a posteriori : la faille PolyShell, exploitée via l’upload de fichiers malveillants dans le dossier des options de commande personnalisées (pub/media/custom_options/quote/). Cette faille permettait à un attaquant de déposer un fichier PHP déguisé en fichier image et de l’exécuter directement via son URL.

Ce que l’attaquant avait mis en place

Webshells

Plus de 400 fichiers PHP malveillants dans pub/media/ — portes dérobées permanentes donnant accès complet au serveur

Skimmer JS

Code JavaScript injecté dans un bloc CMS de la page checkout — capturait les données de carte bancaire à la saisie et les exfiltrait vers un serveur externe

Compte admin frauduleux

Un compte administrateur créé à l’insu du propriétaire — permettait un accès persistant à l’interface d’administration même sans les webshells

Heure par heure — les 4 heures d’intervention

Chronologie de la remédiation

H+0

Signalement et triage

Réception du signalement client. Première analyse des logs serveur et des fichiers récemment modifiés. Confirmation de la compromission — décision de passer en mode incident.

H+0.5

Isolation et préservation

Activation du mode maintenance Magento pour isoler la boutique sans couper le serveur. Sauvegarde complète de l’état compromis pour analyse forensique. Purge du cache Varnish pour supprimer immédiatement le skimmer JS du cache.

H+1

Détection des webshells

Scan systématique du répertoire pub/media/ à la recherche de fichiers PHP — 400+ fichiers malveillants identifiés et supprimés. Vérification étendue à l’ensemble des répertoires accessibles publiquement.

H+2

Nettoyage du skimmer et du compte frauduleux

Identification du bloc CMS contenant le code malveillant via analyse SQL directe en base. Suppression du script JavaScript d’exfiltration. Audit complet des comptes administrateurs — identification et désactivation du compte créé par l’attaquant. Réinitialisation des mots de passe et tokens de session.

H+3

Correction de la vulnérabilité

Déploiement du module Maxcode_FileOptionFix — patch applicatif corrigeant la validation des uploads de fichiers sur les options de commande. Tests approfondis sur l’ensemble des fonctionnalités affectées.

H+4

Upgrade et remise en ligne

Upgrade vers Magento 2.4.7-p9 incluant le correctif natif de PolyShell. Application des patches de sécurité en attente. Tests tunnel de commande complets. Désactivation du mode maintenance — boutique remise en ligne.

Le vecteur d’attaque — comprendre PolyShell

La faille exploitée ici est connue sous le nom de PolyShell. Elle tire son origine d’une validation insuffisante des fichiers uploadés via les options de commande personnalisées de type « File » dans Magento. Un attaquant pouvait déposer un fichier PHP dont l’extension était masquée ou dont le type MIME était falsifié. Magento stockait ce fichier dans un répertoire accessible publiquement sur le web, et l’attaquant pouvait ensuite l’exécuter directement via son URL — lui donnant un accès shell complet au serveur.

Cette vulnérabilité existait depuis les premières versions de Magento 2 et n’a reçu un correctif natif officiel qu’avec le bulletin APSB26-05 intégré dans les patches de sécurité de début 2026. Pendant toute cette période, les boutiques exposées pouvaient être compromises sans qu’aucune erreur visible ne se manifeste côté utilisateur.

Les trois indicateurs qui auraient permis une détection plus précoce

Fichiers suspects dans pub/media/

Des fichiers avec des extensions .php dans un répertoire normalement réservé aux médias — un scan régulier de ce type de fichiers aurait détecté l’intrusion bien plus tôt

Requêtes réseau vers l’extérieur

Le skimmer JS envoyait des données vers un domaine externe — visible dans les logs réseau ou les rapports Content Security Policy si la boutique en avait une

Compte admin inconnu

Un compte administrateur que personne ne reconnaît — une vérification périodique de la liste des comptes admin est un réflexe de sécurité basique souvent négligé

Ce qui a été mis en place pour éviter la récidive

Au-delà de la remédiation immédiate, plusieurs mesures structurelles ont été déployées pour réduire durablement la surface d’attaque :

Règle Apache — blocage de l’exécution PHP dans pub/media/

Une règle .htaccess empêchant l’exécution de tout fichier PHP dans les répertoires de médias — même si un webshell réussissait à s’y déposer, il ne pourrait plus être exécuté

Module Maxcode_FileOptionFix

Patch applicatif sur la validation des uploads — renforcement du contrôle du type MIME et de l’extension réelle des fichiers uploadés via les options de commande

Surveillance des fichiers PHP dans pub/

Mise en place d’un scan automatique périodique pour détecter l’apparition de fichiers PHP dans les répertoires publics

Audit des comptes admin

Revue et nettoyage des comptes administrateurs — restriction des accès au strict nécessaire

Processus de mise à jour régularisé

Mise en place d’un suivi mensuel des patches de sécurité — les délais d’application sont désormais de quelques jours, pas de plusieurs mois

Ce que ce cas illustre sur la sécurité Magento

Plusieurs enseignements ressortent de cette intervention, qu’on retrouve dans la quasi-totalité des cas de compromission Magento que nous traitons :

La compromission précède toujours le signalement de plusieurs semaines. Dans ce cas, le skimmer était actif depuis environ trois semaines avant que les premiers clients se manifestent. Pendant ce temps, des centaines de transactions avaient eu lieu avec le code malveillant actif.

Les patches de sécurité en retard sont le vecteur numéro un. La faille exploitée était connue, documentée, et un patch existait. Le délai d’application — plusieurs mois — a suffi aux attaquants pour exploiter la fenêtre d’exposition.

La remédiation ne se limite pas à supprimer les fichiers malveillants. Supprimer les webshells sans colmater la brèche d’origine ne sert à rien — l’attaquant peut re-déposer ses fichiers en quelques minutes. La séquence correcte est : isoler → analyser → corriger la vulnérabilité → nettoyer → surveiller.

FAQ

Comment savoir si ma boutique a été compromise de la même façon ?

La commande suivante permet de détecter la présence de fichiers PHP dans les répertoires publics de Magento :

find pub/media/ pub/static/ -name "*.php" -type f 2>/dev/null

Si cette commande retourne des résultats, c’est un signal d’alerte fort. Vérifiez également la liste des comptes administrateurs et l’ensemble des blocs CMS de votre page checkout pour détecter la présence de code JavaScript inattendu.

Mes clients dont les données ont été volées doivent-ils être prévenus ?

Oui — et c’est une obligation légale en France. Le RGPD impose de notifier la CNIL dans les 72 heures suivant la découverte d’une violation de données à caractère personnel, et d’informer les personnes concernées si la violation est susceptible d’engendrer un risque élevé pour leurs droits et libertés. Une compromission de données bancaires entre dans ce cadre. Consultez un professionnel juridique pour vous accompagner dans cette démarche.

Puis-je gérer ce type d’incident seul ?

La partie technique de la remédiation — suppression des webshells, nettoyage des blocs CMS, correction de la vulnérabilité — est faisable avec de bonnes compétences Magento et Linux. Ce qui est plus difficile à gérer seul : s’assurer qu’aucune backdoor ne subsiste, identifier avec certitude toute la durée d’exposition, et mettre en place les mesures structurelles pour éviter la récidive. Une deuxième paire d’yeux spécialisée sur un incident de ce type vaut toujours l’investissement.

Vous avez un doute sur l’état de sécurité de votre boutique Magento ?

On fait un audit de sécurité complet — fichiers suspects, comptes admin, patches manquants, blocs CMS — et on vous donne un rapport clair sur ce qui nécessite une action immédiate.

Demander un audit de sécurité →

L’article Intrusion sur une boutique Magento : retour d’expérience d’une remédiation en 4h est apparu en premier sur eBusiness360.

Archives des Cas client - eBusiness360