StyleSmuggler : le rapport de crash était la charge

Adobe a publié un correctif hors cycle le 7 septembre pour CVE-2026-75650, une exécution de code à distance sans authentification notée CVSS 10.0, touchant Adobe Commerce, Adobe Commerce B2B et Magento Open Source. La CISA l’a ajoutée au catalogue des vulnérabilités activement exploitées dès le lendemain. Toutes les versions de 2.4.4 à 2.4.9 sont concernées, ainsi que B2B 1.3.3 à 1.5.3. Tout ce qui tourne en 2.2, 2.3 ou 2.4.0 à 2.4.3 n’est plus maintenu et ne recevra aucun correctif officiel.

Sansec, qui a reproduit la chaîne et l’a baptisée StyleSmuggler, situe la première exploitation confirmée au 4 septembre à 22h20 UTC. Les premiers sondages infructueux remontent au 23 août. Le correctif est arrivé le 7 septembre à 20h20 UTC. Soit deux semaines de reconnaissance et trois jours d’exploitation confirmée avant qu’un correctif existe.

Ce qui est intéressant, c’est la première étape

La plupart des injections de gabarit tiennent en un seul mouvement : vous placez votre entrée dans un gabarit, le moteur l’évalue, c’est gagné. Celle-ci en demande deux, et le premier mouvement est ce qui vaut la lecture.

L’attaquant envoie du code PHP dans la chaîne de requête vers /paypal/transparent/response/. La requête échoue. Magento fait alors ce qu’il est censé faire quand une requête échoue : il écrit un rapport. Ce rapport, dans var/report/<sha256>, contient l’intégralité de la requête — PHP compris.

Le mécanisme de journalisation d’erreurs de l’application est la primitive d’écriture. Rien n’était mal configuré. Le rapport d’erreur a fonctionné exactement comme prévu, et ce comportement prévu a déposé des octets contrôlés par l’attaquant sur le disque, à un chemin prévisible.

La seconde étape est un POST vers /graphql qui assemble une chaîne de gadgets à partir de paramètres styles :

styles[first]=../var/report/<sha256>
styles[generatorClass]=Aws\S3\S3Client

Cela atteint le ClassMapAutoloader de Laminas, qui traite le fichier de rapport comme une table de classes PHP et l’inclut. Le code s’exécute pendant que Magento rend son e-mail standard Payment Transaction Failed Reminder. Neutralisation incorrecte d’éléments spéciaux dans un moteur de gabarits — CWE-1336 — mais atteinte de biais, par l’autochargeur, en combinant deux comportements de framework parfaitement raisonnables pris séparément.

Corriger n’est pas assainir

C’est ici que je nuancerais la façon dont l’avis se lit pour un exploitant pressé. Appliquer VULN-39341 ferme la porte. Cela ne fait rien contre ceux qui sont déjà passés.

La clé de chiffrement de Magento protège les jetons d’intégration, les identifiants de passerelle de paiement et les jetons d’automatisation à privilèges système. Un attaquant disposant de l’exécution de code possède cette clé, donc tout ce qu’elle déchiffre. Faire tourner la seule clé relève du théâtre : il faut faire tourner tous les identifiants jamais chiffrés avec elle — jetons d’API, identifiants de passerelle, mots de passe d’administration, accès base de données, clés SSH.

Si votre boutique était joignable et non corrigée entre le 4 et le 7 septembre, considérez-la comme compromise jusqu’à preuve du contraire. Pas l’inverse.

Où chercher

Vérifiez d’abord que le correctif est réellement appliqué :

vendor/bin/magento-patches -n status | grep "39341\|Status"

Puis cherchez. Les indicateurs publiés par Sansec :

• Des processus d’arrière-plan aux noms plausibles — [kworker/u:8:0], fc-cache, chronyd
• Des fichiers PHP sous pub/media/, qui ne devrait jamais contenir de code exécutable
• Des entrées cron lançant des binaires depuis /tmp ou un répertoire personnel
• Des exceptions journalisées contenant Map file provided does not exist à côté de Laminas\Loader\Exception

La dernière est la plus utile, et il vaut la peine de comprendre pourquoi. C’est la trace de l’échec — l’autochargeur qui se plaint que la table de classes visée n’existe pas. Une exploitation réussie est plus silencieuse. Un journal rempli de ces erreurs signifie que quelqu’un vous travaillait ; un journal vide ne signifie rien dans un sens comme dans l’autre.

Inspectez aussi var/report/ directement. Le mécanisme de dépôt laisse la charge sur le disque sous un nom dérivé de son contenu, ce qui est singulièrement pratique : l’artefact de la première étape survit, horodaté, que la seconde ait abouti ou non.

Ce qu’il faut en retenir

Personne n’a écrit de ligne vulnérable ici. Un rapport d’erreur qui écrit la requête sur le disque est correct. Un autochargeur qui charge une table de classes est correct. Un moteur de gabarits qui rend un e-mail transactionnel est correct. Le défaut est dans la jointure, et les jointures sont précisément là où l’analyse d’accessibilité cesse de regarder.

Si vous exploitez cette pile : corrigez, puis partez du principe que la clé est partie, et agissez en conséquence.

---

Sources : la recherche StyleSmuggler de Sansec · Adobe APSB26-146 · l’avis Adobe Commerce

Tous les écrits