Un zero-day Magento est activement exploité pour déposer une porte dérobée persistante sur les boutiques en ligne, et Adobe n’a publié aucun correctif. Pour une PME ou une ETI qui vend en ligne, la situation est inconfortable : la vulnérabilité est connue, l’exploitation est confirmée, et la seule réponse disponible n’est pas un patch mais une décision d’exploitation. Cet article propose une méthode pour tenir la ligne quand le correctif n’existe pas encore.
Ce que l’on sait du zero-day Magento en cours d’exploitation
Les attaquants exploitent une faille non authentifiée, vraisemblablement via l’interface GraphQL de Magento et Adobe Commerce, pour installer un implant persistant baptisé Disrex. Les caractéristiques rapportées par les chercheurs de Sansec dessinent un profil défensivement hostile :
- l’implant se camoufle sous un nom de processus imitant un thread noyau, du type
[kworker/u:8:0]; - la persistance passe par une entrée cron, mécanisme légitime et rarement surveillé ;
- il peut rester silencieux, sans connexion sortante, ce qui neutralise une bonne partie de la détection réseau ;
- aucun identifiant CVE n’était attribué au moment des premières publications, et aucun correctif éditeur n’est disponible.
Autrement dit, ce zero-day Magento échappe simultanément aux trois réflexes habituels : le scan de vulnérabilités ne le référence pas, la surveillance des flux sortants ne le voit pas, et le cycle de patch ne peut rien pour vous.
Pourquoi l’absence de correctif change la nature de la décision
La gestion de vulnérabilités classique repose sur un pari implicite : le risque est temporaire, parce qu’un correctif finira par arriver. Toute la discipline consiste alors à réduire la fenêtre entre la publication et le déploiement. Nous en avons détaillé la mécanique dans notre article sur la réduction de la fenêtre de patch.
Un zero-day sans correctif casse ce pari. La fenêtre n’est pas courte : elle est indéterminée. Vous ne pilotez plus un délai, vous arbitrez une exposition. Et cet arbitrage n’est plus technique, il est métier : accepte-t-on de dégrader une fonctionnalité de la boutique pour supprimer une surface d’attaque ?
La recommandation défensive : désactiver GraphQL
La mitigation avancée par les chercheurs est explicite : désactiver GraphQL immédiatement si l’usage le permet. C’est une réduction de surface, pas une correction. Elle a un coût — certains front-ends découplés et applications mobiles en dépendent — et c’est précisément pour cela qu’elle doit être décidée par le métier, pas subie par l’IT.
La bonne question n’est pas « peut-on désactiver GraphQL ? » mais « combien de chiffre d’affaires transite réellement par ce chemin, et pendant combien de jours accepte-t-on d’y renoncer ? ». Une PME-ETI capable de répondre à cette question en une heure a un avantage décisif sur une organisation qui doit d’abord la cartographier.
Réagir sans détruire les preuves
Le point le plus contre-intuitif de cet incident concerne la réponse. Le réflexe naturel face à un serveur suspect — redémarrer — est ici le pire choix possible : l’implant vivant en mémoire, un redémarrage détruit l’échantillon avant toute analyse.
La séquence recommandée pour une boutique compromise par ce zero-day Magento est donc la suivante :
- Préserver avant tout : capturer la mémoire et l’état des processus avant tout redémarrage ou toute remédiation ;
- Inspecter le cron : lister les tâches planifiées de tous les comptes, y compris ceux du serveur web, et non uniquement celles de root ;
- Traquer l’imposteur : un processus au nom de thread noyau qui possède un exécutable sur disque n’est pas un thread noyau ;
- Purger les sessions : vider le stockage de sessions pour éjecter tout accès administrateur détourné ;
- Faire tourner les secrets : clés de chiffrement, mots de passe administrateurs, jetons d’API paiement et logistique.
Le e-commerce concentre les conséquences
Une boutique en ligne compromise ne perd pas seulement de la disponibilité. Elle expose des données de paiement, des adresses clients, et sert de point de départ à des campagnes de skimming difficiles à détecter côté navigateur. La logique est la même que celle exposée dans notre analyse des scripts tiers et de la supply chain web : la valeur de la cible ne se mesure pas au serveur, mais au flux qui le traverse.
Construire une capacité de réponse aux failles sans correctif
Ce zero-day Magento n’est pas un cas isolé : c’est un format d’incident qui se répète. La préparation utile ne porte donc pas sur Magento, mais sur la capacité générique à agir sans patch. Trois éléments la structurent :
- Un inventaire des fonctionnalités désactivables : pour chaque application exposée, savoir à l’avance quels modules, API et endpoints peuvent être coupés, et à quel coût métier ;
- Une surveillance de la persistance : cron, unités systemd, tâches planifiées et comptes de service doivent être versionnés et comparés, car un implant discret sur le réseau reste bruyant sur le disque ;
- Une décision préautorisée : définir en amont qui peut ordonner une dégradation de service et sous quel seuil, pour ne pas perdre 48 heures en arbitrage pendant l’exploitation active.
Face à une faille sans correctif, la maturité d’une organisation ne se mesure pas à sa vitesse de patch mais à sa vitesse de renoncement maîtrisé. Le zero-day Magento exploité actuellement rappelle que la meilleure réponse disponible est parfois de retirer une fonctionnalité, de préserver les preuves, et de faire tourner ce qui a pu être volé — dans cet ordre.