Corriger Magento ne suffira pas à sauver votre boutique : les attaquants étaient entrés trois jours plus tôt

Une faille notée 10 sur 10 dans Magento et Adobe Commerce : ce qui s'est réellement passé

La réponse directe d'abord : le 4 septembre 2026, des attaquants ont commencé à exploiter une faille non corrigée dans Magento Open Source et Adobe Commerce, référencée CVE-2026-75650, avec un score de gravité de 10,0, le plus élevé possible. La faille permet d'exécuter des commandes sur le serveur de la boutique sans aucune connexion ni aucun privilège, et Adobe a publié son correctif le soir du 7 septembre. Cela laisse trois jours entiers pendant lesquels les boutiques étaient exposées sans aucune protection. C'est précisément pourquoi installer le correctif ne suffit pas : si votre boutique fonctionne sur cette plateforme, l'hypothèse prudente est que vous avez pu être compromis avant que le correctif n'existe, et la bonne réponse consiste à rechercher des signes d'intrusion et à renouveler vos clés de chiffrement et tous vos identifiants, et non à installer la mise à jour puis à passer à autre chose.

Qui est concerné, exactement

La liste est inhabituellement large, car elle inclut la version la plus récente disponible au moment de la découverte :

• Magento Open Source et Adobe Commerce : les versions 2.4.4 à 2.4.9, y compris toutes les mises à jour correctives jusqu'en août 2026.
• Adobe Commerce B2B : les versions 1.3.3 à 1.5.3, jusqu'à la mise à jour d'août 2026.
• Toute version antérieure à 2.4.4 : déjà hors support, et la catégorie la plus dangereuse, car le correctif officiel ne la couvre pas.

Pour le dire simplement : si vous utilisiez un Magento entièrement à jour au 1er septembre, vous étiez exposé. Ce n'est pas le scénario de négligence habituel contre lequel nous mettons généralement en garde : c'est une véritable faille zero-day que personne n'avait le moyen d'anticiper.

Comment l'attaque fonctionne sans mot de passe

L'attaque se déroule en deux étapes et détourne la capacité de Magento à construire des modèles d'e-mail. Dans la première étape, l'attaquant envoie une requête forgée vers un chemin de réponse de paiement, et le contenu complet de cette requête est écrit dans un fichier de rapport d'erreur sur le serveur. Dans la seconde étape, une requête vers le point de terminaison GraphQL renvoie vers ce fichier empoisonné, et son contenu s'exécute pendant la préparation d'un e-mail de rappel d'échec de paiement.

Ce qui mérite l'attention d'un chef d'entreprise n'est pas le détail technique, mais ce qu'il révèle : des chemins publics d'apparence parfaitement anodine (une réponse de passerelle de paiement, un point de requête pour la vitrine, un e-mail automatique) combinés en un itinéraire complet vers le serveur. Les vulnérabilités graves sont rarement une seule porte grande ouverte ; bien plus souvent, ce sont une chaîne de petites portes, dont chacune paraît parfaitement raisonnable prise isolément.

Ce que les attaquants ont installé une fois à l'intérieur

C'est là que se voit la différence entre un vandale et une opération organisée. Les charges observées n'étaient pas des messages de rançongiciel bruyants, mais des outils de persistance discrets :

• Une porte dérobée écrite en Rust qui se fait passer pour l'un des processus du noyau du système d'exploitation, afin de ne pas attirer l'attention de quiconque parcourt la liste des processus.
• Un trafic de commande et de contrôle camouflé sur le port de synchronisation de l'heure, de sorte que l'activité ressemble à un réglage d'horloge de routine dans les journaux réseau.
• Des web shells PHP écrits dans les dossiers de cache des images produits, des endroits que personne n'inspecte normalement parce qu'ils sont remplis de fichiers temporaires.
• Des outils d'accès à distance supplémentaires provenant d'un second attaquant aux outils sans rapport, ce qui signifie que la faille était exploitée par plus d'un groupe en même temps.

Le but de telles charges sur une boutique en ligne connue est de rester longtemps et de lire les données de commande et de paiement au fil de leur passage, et non de mettre le site hors ligne. Une boutique infectée continue de fonctionner tout à fait normalement, et c'est bien ce qui est inquiétant.

Pourquoi installer la mise à jour ne suffit pas

Parce que si un attaquant est entré avant le 7 septembre, il détient désormais une copie de vos clés de chiffrement et de vos identifiants stockés. Le correctif ferme la porte par laquelle il est entré ; il ne l'expulse pas de l'intérieur. Les recommandations d'Adobe elles-mêmes étaient explicites sur ce point : appliquer le correctif puis renouveler les clés de chiffrement, les mots de passe du panneau d'administration, les jetons d'API, les identifiants de la passerelle de paiement, les mots de passe de la base de données et les clés d'accès au serveur.

Le correctif arrête l'hémorragie. Renouveler les clés, c'est ce qui fait sortir l'intrus de la maison.

Un plan d'action pratique pour un propriétaire de boutique

• Premièrement : confirmez que le correctif est réellement installé, et pas seulement que quelqu'un l'a affirmé. Demandez à votre équipe une preuve tirée du journal des correctifs sur le serveur lui-même, et non un message rassurant.
• Deuxièmement : recherchez les traces d'intrusion : des processus en cours suspects dont le nom imite des processus système, des fichiers PHP dans les dossiers de médias et d'images, et des fichiers de rapport d'erreur inhabituels.
• Troisièmement : examinez le journal des e-mails sortants. Une hausse soudaine des e-mails de rappel d'échec de paiement est un indicateur direct de tentatives d'exploitation, et tout responsable des opérations peut le lire sans expertise approfondie en sécurité.
• Quatrièmement : renouvelez toutes les clés sans exception, en particulier les identifiants de la passerelle de paiement. Cela exige une fenêtre de maintenance planifiée, et non une décision improvisée aux heures de pointe.
• Cinquièmement : si votre version est antérieure à 2.4.4, cessez d'attendre un correctif officiel qui ne viendra pas. Fixez un plan de mise à niveau avec une vraie date, et placez la boutique derrière un pare-feu applicatif web en attendant.
• Sixièmement : documentez ce que vous avez fait. S'il s'avère que des données clients ont fuité, vous aurez besoin d'une chronologie de ce que vous avez fait et quand.

L'angle réglementaire en Arabie saoudite : les données clients ne sont pas qu'une affaire technique

Une boutique en ligne qui détient les noms, adresses, numéros de mobile et historiques de commandes de ses clients traite des données personnelles régies par la loi sur la protection des données personnelles (PDPL). Une violation ne reste pas une affaire interne entre la boutique et son hébergeur ; elle crée des obligations envers l'autorité compétente et envers les personnes concernées elles-mêmes. La question qu'un propriétaire de boutique devrait se poser aujourd'hui n'est donc pas seulement « le serveur a-t-il été corrigé ? », mais « puis-je démontrer que les données de mes clients n'ont pas été touchées ? ».

Si votre boutique fonctionne sur une plateforme cloud gérée comme Salla ou Zid, vous êtes hors du périmètre de cette faille précise, car la correction de la plateforme ne relève pas de votre responsabilité. Mais la même leçon s'applique à toute extension ou intégration tierce que vous avez branchée sur votre boutique : la responsabilité des correctifs suit le propriétaire du serveur.

Comment nous gérons ce type d'incident chez Origami

Le principe sur lequel nous construisons les systèmes de nos clients est qu'un incident de sécurité n'est pas une possibilité lointaine mais un événement différé. Concrètement, cela signifie trois choses : des identifiants conservés hors du code, dans un coffre séparé, pour que leur renouvellement soit une tâche de quelques minutes plutôt qu'un projet d'une semaine ; des journaux d'exploitation stockés hors du serveur lui-même, pour qu'un attaquant ne puisse pas effacer ses propres traces ; et des sauvegardes réellement testées par restauration, et non simplement planifiées.

Et si vous exploitez une boutique Magento sans équipe technique dédiée, la bonne démarche aujourd'hui est simple : demandez à votre hébergeur ou à votre partenaire technique un rapport écrit répondant à trois questions seulement : quand exactement le correctif a été installé, ce qu'a révélé l'analyse de compromission, et si les clés ont été renouvelées. Ces trois questions en disent plus sur la préparation d'un partenaire technique que n'importe quelle présentation.

Sources

• Annonce officielle d'Adobe Commerce concernant la mise à jour de sécurité APSB26-146 et le correctif urgent : experienceleague.adobe.com
• Analyse technique de Sansec sur la CVE-2026-75650 et les indicateurs de compromission : sansec.io/research/stylesmuggler-0day
• Catalogue des vulnérabilités exploitées connues de la CISA : cisa.gov
• Loi sur la protection des données personnelles (PDPL), Autorité saoudienne des données et de l'intelligence artificielle (SDAIA) : sdaia.gov.sa