The Magento malware campaign compromised 953 online stores between July 2025 and October 2026, according to Sansec’s October 24, 2026 investigation. The injected JavaScript fingerprints visitors and can withhold its payload from automated scanners, so a clean crawl doesn’t prove a store is safe. Merchants should audit CMS database content, administrator access, API integrations, server persistence and shoppers’ browser storage.
Un chargeur de bloc CMS est un code malveillant inséré dans le contenu des pages géré par la base de données afin qu’une vitrine charge du JavaScript contrôlé par un attaquant. Dans cette campagne, supprimer le script visible ne suffit pas : l’accès conservé au serveur et le code enregistré dans le navigateur localStorage peuvent survivre à un nettoyage superficiel.
Que fait la campagne de logiciels malveillants Magento ?
La campagne de logiciels malveillants Magento place un chargeur JavaScript dans le contenu CMS de Magento ou d’Adobe Commerce, établit le profil du navigateur de chaque visiteur et diffuse sélectivement du code supplémentaire. Sansec a indiqué le 24 octobre 2026 que l’opération avait compromis 953 boutiques depuis juillet 2025 et qu’elle était associée à cinq domaines de chargeurs principaux.
Sansec a trouvé le chargeur dans le champ de base de données cms_block.content . Son scanner a identifié cet emplacement sur 148 installations de serveurs en 2026, sans trouver de chargeur de la campagne dans core_config_data ou dans les fichiers de thème. Les commerçants ne devraient pas limiter leur recherche aux modèles simplement parce que de nombreuses enquêtes antérieures sur Magecart ont commencé à cet endroit.
Le domaine observé le plus récemment, deepveindrilling.com, a été enregistré le 6 octobre 2026. Les boutiques ont commencé à le charger le 7 octobre, Sansec enregistrant la première détection à 21:54 UTC. Le 8 octobre, le robot d’exploration de Sansec avait identifié la version initiale à deux scripts sur 74 boutiques ; le domaine a finalement été observé dans des blocs CMS sur 83 boutiques.
L’ampleur de la campagne a également augmenté par vagues. Sansec a indiqué que lanhd6549tdhse.top avait été injecté dans 471 boutiques en l’espace d’une heure le 30 mars 2026, à la suite de téléversements de webshells PolyShell. Cette découverte provenant d’une seule source représente environ 49.4% du total de 953 boutiques de la campagne : 471 divisé par 953, multiplié par 100.
Comment le logiciel malveillant se dissimule-t-il aux scanners de sécurité ?
The Magento malware campaign evades scanners by collecting automation signals, WebGL and GPU data, CPU core counts, memory, screen dimensions, time zone, languages and browser client hints. On October 24, 2026, Sansec’s automated Chrome session received an HTTP 200 response but no injected content, demonstrating selective delivery.
Le 23 octobre 2026, l’opérateur a remplacé l’ancienne balise de script externe par un chargeur de prise d’empreinte intégré. Neuf boutiques supplémentaires ont reçu le chargeur ce jour-là, et les blocs CMS précédemment infectés ont été réécrits. Lorsque Sansec a réexploré 71 boutiques le 24 octobre, chacune diffusait la version révisée.
Une réponse HTTP réussie peut donc être trompeuse. La surveillance de l’état peut confirmer qu’un domaine distant a répondu, sans jamais voir le code présenté à un acheteur accepté. À mon avis, considérer l’absence de détection lors d’une analyse effectuée avec un navigateur sans interface comme une preuve de remédiation constitue le raccourci le plus dangereux dans cet incident.
Au 24 octobre 2026, Sansec n’avait pas capturé la charge finale transmise à un visiteur accepté par le chargeur le plus récent. L’action finale de la campagne restait donc invérifiée au moment de la publication. Qualifier la charge non observée de skimmer de paiement, de voleur d’identifiants ou de redirection confirmé irait au-delà des éléments disponibles.
Pourquoi l’infection peut-elle subsister après le blocage du domaine ?
La campagne de logiciels malveillants Magento peut persister dans les navigateurs des acheteurs, car un chargeur d’octobre 2026 lisait du code exécutable depuis localStorage.fpCode. Code retained in browser storage can run on later page views after the loader domain is blocked or unavailable, so removing the server-side injection does not erase copies already stored on customer devices.
La version du 7 octobre 2026 plaçait le code stocké dans le gestionnaire onclick d’un élément invisible et l’exécutait sans utiliser eval(). Un scanner qui recherche uniquement des appels manifestes à eval() pourrait ne pas détecter ce comportement. Bloquer le domaine au niveau du DNS ou de la politique de sécurité du contenu arrête un moyen de diffusion, mais pas un ensemble d’instructions déjà mis en cache.
La politique de sécurité du contenu d’Adobe Commerce peut néanmoins fournir de précieux signaux d’alerte. La documentation d’Adobe publiée en 2026 indique qu’Adobe Commerce 2.4.7 et les versions ultérieures utilisent par défaut le mode restrictif sur les pages de paiement et le mode de rapport uniquement ailleurs. Sansec a indiqué avoir reçu environ 52 000 rapports CSP impliquant le domaine antérieur de la campagne additionalver.com en 2026.
Ces rapports peuvent révéler des connexions tierces inattendues même lorsqu’un robot d’exploration ne reçoit rien. Les commerçants devraient conserver les données de télémétrie CSP avant d’effectuer des modifications, puis comparer les URL concernées, les horodatages et les agents utilisateurs avec les enregistrements de mise à jour du CMS.
Comment les commerçants utilisant Magento doivent-ils enquêter et procéder au nettoyage ?
Les commerçants utilisant Magento et Adobe Commerce devraient préserver les éléments de preuve, rechercher dans les champs de la base de données du CMS, identifier les accès non autorisés et supprimer tous les mécanismes de persistance avant de renouveler les identifiants. Les recommandations de Sansec publiées en 2026 indiquent que supprimer uniquement le JavaScript injecté n’élimine pas l’accès à la base de données, les comptes administrateur frauduleux, les intégrations API, les webshells ou les portes dérobées laissés par l’opérateur.
La séquence d’intervention suivante couvre les éléments propres à cette campagne que les commerçants devraient examiner en 2026 :
- Rechercher
cms_block.contentetcms_page.contentpourfpCode,se_referreretlocalStorage.getItem. Incluez les tables de base de données dotées de préfixes personnalisés et préservez les lignes correspondantes avant de les modifier. - Utilisez la valeur
update_timede chaque enregistrement CMS pour reconstituer les modifications non autorisées. Faites correspondre ces horaires avec les connexions des administrateurs, les activités de déploiement, les appels API et les journaux du serveur. - Inspecter
admin_userpour les comptes inconnus ou réactivés de manière inattendue. Examinez les intégrations d’API et les processus inhabituels plutôt que de supposer que l’injection dans la base de données était le seul point d’accès de l’attaquant. - Recherchez
accesson.php, GSocket et les fichiers exécutables ou déguisés souspub/media/custom_options/etpub/media/customer_address/. - Appliquez les mises à jour de sécurité Adobe pertinentes, procédez à un nettoyage forensique complet, puis renouvelez les identifiants de la base de données, des administrateurs et des intégrations d’API. Renouveler les identifiants avant de supprimer la persistance pourrait fournir de nouveaux identifiants à l’attaquant.
L’état des correctifs mérite d’être nuancé. Sansec a signalé en 2026 que 169 installations Magento 2 affectées n’avaient pas au moins un correctif du cœur ; 102 de ces boutiques, soit 60%, contenaient également des fichiers associés à PolyShell ou SessionReaper. Pourtant, une boutique Magento 2.4.7-p10 sans aucun correctif du cœur manquant a reçu le nouveau chargeur le 23 octobre 2026, après la détection d’un administrateur malveillant le 16 septembre et d’une porte dérobée GSocket le 24 septembre.
Ce cas particulier est important. Un logiciel entièrement corrigé peut être réinfecté lorsqu’une compromission plus ancienne laisse derrière elle un accès valide ou une persistance sur le serveur. En toute honnêteté, appliquer des correctifs sans examiner les comptes et les artefacts du système de fichiers n’a de sens que comme mesure temporaire de confinement, et non comme réponse achevée.
Quelles vulnérabilités et campagnes sont liées ?
La campagne de logiciels malveillants Magento présente des liens constatés avec d’anciens artefacts de compromission PolyShell et SessionReaper, mais elle est distincte de StyleSmuggler. Adobe a publié la mise à jour APSB26-73 liée à PolyShell le 14 juillet 2026, tandis que SessionReaper correspond à CVE-2025-54236, une vulnérabilité CVSS 9.1 corrigée par APSB25-88 le 9 septembre 2025.
| Événement | Date | Relation avec cette campagne | Action du commerçant |
|---|---|---|---|
| SessionReaper, CVE-2025-54236 | Avis du 9 septembre 2025 | Des fichiers associés sont apparus sur certaines boutiques affectées dans l’échantillon 2026 de Sansec | Vérifiez la couverture d’APSB25-88 et recherchez les accès antérieurs |
| PolyShell, CVE-2026-48356 | Mise à jour du 14 juillet 2026 | Des artefacts de webshell et une injection rapide du chargeur ont été signalés par Sansec en 2026 | Installez APSB26-73 et recherchez les mécanismes de persistance |
| StyleSmuggler, CVE-2026-75650 | Correctif du 7 septembre 2026 | Chaîne distincte d’exécution de code à distance sans authentification | Appliquez son correctif, mais ne le présentez pas comme l’origine de la campagne visant les blocs CMS |
| Réécriture du chargeur d’empreinte | 23 octobre 2026 | L’opérateur de la campagne a ajouté une diffusion sélective basée sur le navigateur | Utilisez les éléments de preuve provenant de la base de données, des accès et de la CSP plutôt que les seuls résultats des robots d’exploration |
Adobe a ensuite confirmé l’exploitation de SessionReaper dans la nature, selon son bulletin de sécurité APSB25-88. Sansec recommande d’installer APSB26-73 tout en enquêtant sur la nouvelle campagne, mais aucune de ces mises à jour ne supprime les comptes malveillants, les enregistrements CMS modifiés ou les portes dérobées créés avant l’application des correctifs.
La première exploitation confirmée de StyleSmuggler a eu lieu le 4 septembre 2026, et Adobe a publié son correctif trois jours plus tard. Notre analyse distincte du zero-day StyleSmuggler de Magento explique cette chaîne d’exploitation. Mélanger ces incidents peut orienter les intervenants vers les mauvais indicateurs et produire une chronologie de compromission inexacte.
FAQ sur la campagne de logiciels malveillants Magento
Un scan Magento propre peut-il prouver que la boutique est sûre ?
Non. La campagne de logiciels malveillants ciblant Magento a dissimulé le contenu injecté au navigateur Chrome automatisé de Sansec le 24 octobre 2026, malgré le renvoi d’un code HTTP 200. Une inspection de la base de données, un examen des comptes et une analyse forensique du serveur sont donc nécessaires en complément de l’analyse du navigateur.
Où les commerçants doivent-ils rechercher le code malveillant ?
Les commerçants doivent rechercher cms_block.content et cms_page.content pour fpCode, se_referrer et localStorage.getItem, y compris les tables de base de données préfixées. Sansec a identifié le chargeur de la campagne dans cms_block.content sur 148 installations de serveurs en 2026.
Le blocage de deepveindrilling.com supprime-t-il l’infection ?
Non. Bloquer deepveindrilling.com peut interrompre ce chemin réseau, mais le code enregistré dans le navigateur localStorage peut s’exécuter lors de visites ultérieures, et la boutique peut conserver des comptes malveillants, un accès à la base de données ou des portes dérobées sur le serveur.
StyleSmuggler était-il responsable des 953 boutiques compromises ?
Non. StyleSmuggler, répertorié sous le numéro CVE-2026-75650, constitue une chaîne d’exploitation distincte datant de septembre 2026. L’opération touchant 953 boutiques, documentée par Sansec le 24 octobre 2026, se concentre sur l’injection récurrente de chargeurs dans les bases de données des CMS, la diffusion sélective et le maintien de l’accès.