Magento : une faille exploitée, aucun correctif

Ce qui se passe

Sansec a publié le 5 septembre un avis sur une faille de Magento Open Source et Adobe Commerce exploitée depuis le 4 septembre, et l'a nommée StyleSmuggler. L'éditeur néerlandais explique publier tôt parce que des boutiques tombent en ce moment même.

Au 6 septembre, Adobe n'a rien publié : ni identifiant CVE, ni correctif, ni contournement. Son index de bulletins de sécurité Adobe Commerce ne contient rien après la mise à jour du 11 août. La prochaine publication de sécurité est annoncée pour le 8 septembre, sans garantie qu'elle couvre cette faille.

Sansec dit avoir reproduit la chaîne complète, sans authentification, sur des installations propres de Magento Open Source 2.4.7, 2.4.8 et 2.4.9. Sa première victime tournait en 2.4.6-p15 avec les correctifs de juillet et août 2026 appliqués — le niveau le plus élevé qu'Adobe propose pour cette branche.

Comment la chaîne fonctionne

L'attaque se déroule en deux temps, et sa deuxième moitié explique pourquoi elle passe inaperçue : le déclencheur est une fonction normale de Magento.

Le code s'exécute au rendu du message, donc personne n'a besoin de l'ouvrir, et l'attaque réussit même si l'envoi du courriel échoue.

Disrex Group, hébergeur qui a traité deux boutiques compromises, situe la fin de la chaîne dans trois fichiers sous setup/src/Magento/Setup/Module/Di/Code/ — du code destiné au compilateur d'injection de dépendances en ligne de commande, atteint ici par HTTP. Ni Sansec ni Adobe n'ont confirmé cette lecture.

Ce qu'il faut chercher

Le dropper PHP essaie six fonctions successives pour lancer un processus, puis télécharge l'implant : un binaire Rust d'environ 1,9 Mo, statique, compilé pour x86-64 et arm64.

• Processus : [kworker/u:8:0] appartenant à un utilisateur non-root. Un vrai fil du noyau appartient à root et n'a pas de mémoire résidente.
• Fichiers : ~/.local/share/.gvfsd/gvfsd-user, ~/.local/share/.gvfsd/.gvfsd_<8hex>.lock, /tmp/.gvfsd_<8hex>.lock, /tmp/.kw_<aléatoire>.
• Cron : */5 * * * * écrit directement dans /var/spool/cron/crontabs/, donc invisible dans les journaux système. Une boutique portait la ligne 1 728 fois.
• SHA-256 : e315687a1dfe61ef4a5a5642214db6d3b2b05d81391285eebc2af664641a26a7 (échantillon Sansec), 8334b434fa3fe9f59cebe9609b11e0b1fd19d10212c45c705adec1902a1d06ef (sur disque), 251fabd50d7b18a8b5e1b3ef5d64e7198c17244778f6461fb1ab07f6169bf220 (en mémoire — les deux diffèrent, hachez aussi /proc/<pid>/exe).
• Réseau : 247.cdnflare[.]xyz pour le téléchargement, 99.84.67[.]186:443 en commande et contrôle, 88.216.72[.]181 et 5.181.86[.]133 en source.

Deux répertoires sont à fouiller, pas un : la vérification publiée par Sansec cherche le marqueur X_TRACE_ dans var/report/, alors que les deux infections Disrex sont passées par var/log/system.log. L'en-tête déclencheur a d'ailleurs changé de forme en une journée — cherchez le motif, pas la chaîne exacte.

Ce que ça change

Le point que les marchands doivent entendre est celui-ci : le niveau de correctif n'a rien changé. Les deux boutiques compromises l'ont été dans la fenêtre d'environ huit heures entre la première exploitation observée et l'existence de la moindre défense. L'une était abonnée au pare-feu applicatif de Sansec, module installé et actif.

En attendant Adobe :

• couper GraphQL si la vitrine s'en passe — les boutiques classiques et Hyvä n'en ont pas besoin, les vitrines headless et PWA si ;
• ajouter proc_open à disable_functions : sur une des deux boutiques, quatre des six fonctions essayées étaient désactivées, proc_open non ;
• monter /tmp, /var/tmp et /dev/shm en noexec.

Ces deux dernières mesures ne dépendent pas de la chaîne, donc elles survivront aux variantes. Des correctifs non officiels circulent (Disrex, ProxiBlue, Graycore) ; les deux premiers sont le même correctif et ne doivent pas être empilés.

À retenir

Un scanner peut mentir par cadrage : chez Disrex, l'analyse programmée pointait la racine web alors que l'implant s'installait un répertoire au-dessus, dans le répertoire personnel du compte. Elle a rendu un verdict « propre » onze heures après l'infection.

Source : The Hacker News