Magecart : définition et protection de l'e-commerce, carte et Pix

Magecart est le nom donné aux attaques qui placent un code malveillant sur la page de paiement d'une boutique en ligne légitime pour détourner ce que le client saisit ou paie. Pendant des années, la cible a été le numéro de carte. En septembre 2026, une campagne au Brésil a montré le même type de code en train de remplacer le QR du Pix (le système de paiement instantané de la Banque centrale du Brésil). La boutique reste en ligne, avec la bonne marque et le bon prix, et le client ne voit rien d'anormal.

D'où vient le nom

Le nom associe Mage, de Magento, et cart, « panier » en anglais. Des chercheurs ont commencé à l'employer au milieu de la décennie précédente pour désigner les groupes qui attaquaient les paniers d'achat de cette plateforme. Avec le temps, le terme a fini par désigner la technique elle-même, sur n'importe quelle plateforme e-commerce, dans une boutique développée en interne comme dans un service tiers.

Ce qui définit une attaque Magecart, ce n'est pas l'outil utilisé, mais l'endroit : la page où le client indique comment il va payer.

Comment fonctionne une attaque Magecart

1. Entrée. Le code arrive par une faille non corrigée de la plateforme, par un plugin ou un thème vulnérable, par un mot de passe d'administration divulgué ou par un script tiers compromis. En juin 2024, un seul service de scripts utilisé par plus de 100 000 sites s'est mis à distribuer du code malveillant après avoir changé de propriétaire.
2. Camouflage. Le fragment tient souvent en quelques lignes obscurcies et se loge dans un fichier légitime, dans une image ou dans un service que la boutique considère déjà comme fiable. En avril 2026, des chercheurs ont trouvé le code caché dans une image invisible sur environ 100 boutiques. En juin, une autre famille stockait le code et les données volées dans un service de paiement connu, pour que le trafic paraisse normal.
3. Action uniquement au paiement. Le code reste inactif sur les autres pages. Quand le client arrive au paiement, il lit les champs de la carte de crédit ou de la carte de débit, ou remplace le QR, le Pix Copia e Cola (le code de paiement en texte que le client copie puis colle dans l'application de sa banque) ou la linha digitável (le numéro du boleto) du boleto (le bordereau de paiement bancaire brésilien).
4. Sortie. Avec la carte, les données partent vers un serveur de l'attaquant et sont utilisées plus tard. Avec le Pix, c'est le client lui-même qui envoie l'argent sur le mauvais compte, immédiatement.

Les affaires qui ont défini le problème

• British Airways, 2018. Un script modifié sur le site et dans l'application a copié des données de paiement pendant environ deux semaines. L'autorité britannique de protection des données a recensé 429 612 personnes touchées et a infligé une amende de 20 millions de livres en octobre 2020.
• Europol, 2023. Une opération coordonnée par Europol a alerté des centaines de boutiques en ligne dans plusieurs pays qui avaient un code de vol de données de carte actif sur leur page de paiement, la plupart sans le savoir.
• 2026. Les recherches de l'année montrent le code migrant vers des endroits que les défenses courantes ne regardent pas : dans des images et dans des services de paiement légitimes, là où la boutique cherche rarement.
• Brésil, septembre 2026. Le chercheur indépendant connu sous le nom d'eremit4 a identifié, et Kaspersky a confirmé, 90 boutiques de petite et moyenne taille dont le code remplaçait le QR et le Pix Copia e Cola sur la page de paiement. Quand le client choisissait la carte, le même code copiait les données. Le chercheur a baptisé l'affaire « le nouveau magecart brésilien ». Nous détaillons ce cas dans Magecart sur le Pix.

Pourquoi la boutique tarde à s'en rendre compte

Avec la carte, la vente est acceptée et l'argent rentre. Le préjudice apparaît des semaines plus tard, sur le relevé du client, et ce n'est qu'en recoupant plusieurs cas que la banque émettrice conclut que tous ont acheté dans la même boutique.

Avec le Pix, la vente n'entre tout simplement pas. Le back-office affiche une commande en attente ou abandonnée, et la réclamation arrive des jours plus tard, quand le produit n'a pas été expédié. Les commerçants touchés en 2026 ont d'abord constaté une hausse des abandons, avant de comprendre ce qui se passait.

Dans tous les cas, le serveur peut sembler sain. Si le code vient de l'extérieur ou est assemblé dans le navigateur, la copie des fichiers de la boutique ne change pas. Ce qui change, c'est ce que voit le client.

Ce que demande le PCI DSS

Depuis le 31 mars 2025, les exigences 6.4.3 et 11.6.1 du PCI DSS sont obligatoires pour qui accepte la carte en ligne. La 6.4.3 demande un inventaire des scripts de la page de paiement, avec une justification et une garantie d'intégrité pour chacun. La 11.6.1 demande un mécanisme qui détecte les modifications non autorisées de la page et des en-têtes de sécurité, avec une vérification au moins hebdomadaire.

Les deux ont été rédigées à cause du Magecart sur la carte. Elles ne parlent ni du Pix ni du boleto, alors que le code qui remplace un QR s'exécute sur la même page et par le même chemin. Nous détaillons les deux exigences dans scripts tiers sur la page de paiement.

Comment protéger l'e-commerce contre Magecart

1. Fermez les portes d'entrée. Mettez à jour la plateforme, le thème et les plugins, et supprimez ce qui ne sert pas. La plupart des campagnes exploitent des failles connues et déjà corrigées.
2. Protégez le back-office. Double authentification pour tous les administrateurs, revue des comptes qui ont un accès et changement des mots de passe des intégrations.
3. Réduisez ce qui s'exécute sur la page de paiement. Chaque script de la page de paiement doit avoir un responsable et une raison d'être. Chat, carte de chaleur et pixel publicitaire ont rarement leur place ici.
4. Préférez les champs de carte hébergés par le prestataire. Ils réduisent le risque de copie directe, mais la page autour peut toujours afficher un faux formulaire. Voir ce que les champs hébergés règlent et ce qu'ils ne règlent pas.
5. Limitez les destinations vers lesquelles la page peut envoyer des données. Une politique de sécurité du contenu bien configurée gêne l'envoi vers des serveurs inconnus. Elle n'aide pas quand l'attaquant utilise un service que la boutique a déjà autorisé.
6. Surveillez la page telle que le client la voit. Le fichier sur le serveur peut être correct et l'écran être faux. Voir comment surveiller les modifications de la page de paiement.
7. Vérifiez le code de paiement affiché. Pour le Pix, le boleto et le portefeuille de stablecoins, comparez ce qu'affiche l'écran avec ce que la boutique a émis, avant que le client paie.
8. Ayez un plan pour le jour de l'incident. Qui désactive le moyen de paiement touché, qui parle au prestataire, comment prévenir les clients et comment conserver les preuves.

Signes que la boutique a peut-être été touchée

• Une hausse des Pix en attente, sans baisse équivalente des visites sur la page de paiement.
• Des clients qui disent avoir payé alors que la commande n'a pas été validée, avec un justificatif au nom d'une autre entreprise.
• Une alerte du prestataire de paiement ou de l'acquéreur sur des cartes utilisées frauduleusement après des achats dans la boutique.
• Des fichiers modifiés sans que personne n'ait rien publié, ou un administrateur que personne ne reconnaît.
• La page de paiement qui envoie des données vers des domaines que l'équipe ne connaît pas.

Si deux de ces signes apparaissent ensemble, traitez la situation comme un incident jusqu'à preuve du contraire.

Le rôle de Proteside

Proteside est une couche de cybersécurité qui vérifie, sur l'écran de celui qui paie, que les données de paiement sont bien celles émises par le vendeur, et bloque le remplacement avant la confirmation. Il réalise l'inventaire des scripts exigé par le PCI DSS et va plus loin : il compare le QR, le Copia e Cola, la linha digitável et le formulaire de carte avec ce que la boutique a généré, à chaque commande, et enregistre chaque tentative comme preuve. Voir comment il fonctionne pour la carte de crédit et pour la conformité au PCI DSS.