Le fil de l’actualité

Écrit par l’IASécurité

Magento sous une faille CVSS 10 : un guide de vérification avant le correctif pour Adobe Commerce

Comment prouver qu'une boutique Magento ou Adobe Commerce est corrigée, chasser les webshells et les gabarits modifiés, et déployer le correctif BlockStrap sans casser la vitrine.

Baie de serveurs dans une salle de données sombre, icône de panier lumineuse et cadenas fissuré

Rédigé par une IA. Cette analyse a été rédigée par une IA et publiée sans relecture ligne par ligne.

Dans l’actualité

Un numéro de version est le mensonge le plus confortable de l’exploitation web. Sur une boutique PHP, « nous sommes en 2.4.9 » indique la ligne de publication et rien de plus sur la présence réelle du correctif sur le disque. Cet écart est toute l’histoire de BlockStrap, la faille de gravité maximale qu’Adobe a divulguée pour Magento et Adobe Commerce en octobre. Ce guide répond à la question qui survit au cycle des nouvelles : comment prouver qu’une boutique est protégée, vérifier si elle a déjà été touchée, et la corriger sans casser le build? BlockStrap sert d’exemple, et je précise où les sources publiques s’arrêtent.

Avant de lire : La logique de tri des CVE vient de Triage des correctifs du mardi : classer des centaines de CVE avec KEV, EPSS et l’exposition, et les vérifications « étions-nous déjà à l’intérieur? » reprennent la méthode de Zero-days sur appareils de périmètre : un runbook d’urgence pour VPN, passerelles et pare-feu. Aucun des deux n’est obligatoire, mais ils expliquent les réflexes utilisés ici.

Pourquoi maintenant : Adobe a publié le bulletin APSB26-153 le 13 octobre, classé priorité 2, et affirme ne connaître aucune exploitation en nature pour les problèmes qu’il contient. Le 16 octobre, BleepingComputer rapportait que Sansec n’avait observé aucune attaque, mais avait identifié quatre chemins d’attaque en moins de 24 heures, et que Sansec conteste la priorité attribuée.

Table des matières

Savoir quelle version vous exécutez

La liste des versions touchées d’Adobe est écrite dans le jargon du fournisseur, et elle récompense une lecture attentive. Les builds Commerce et Open Source portent une ligne de publication suivie d’un suffixe de date : « 2.4.9-2026-sep et antérieures » est vulnérable, et « 2.4.9-2026-oct » est le correctif.

ProduitBuilds touchésBuilds corrigés
Adobe Commerce et Magento Open SourceLignes 2.4.4 à 2.4.9, tous les builds jusqu’au suffixe -2026-sepCommerce : 2.4.4-2026-oct à 2.4.9-2026-oct, plus 2.4.10-alpha1. Open Source : 2.4.7-2026-oct à 2.4.9-2026-oct
Adobe Commerce B2B1.3.3 à 1.5.3, tous les builds jusqu’au suffixe -2026-sep1.3.3-2026-oct à 1.5.3-2026-oct, plus 1.5.4-alpha1

Lisez le tableau deux fois, parce que la rangée Open Source est moins nette qu’elle n’en a l’air. La liste des versions touchées descend jusqu’à 2.4.4, mais la liste des correctifs commence à 2.4.7, et le KB n’offre les téléchargements isolés Open Source qu’à partir de la 2.4.7. Les sources que j’ai consultées ne disent pas quoi faire pour une boutique Open Source en 2.4.4, 2.4.5 ou 2.4.6. Si vous êtes sur une de ces lignes, posez la question à Adobe par écrit avant toute autre chose.

Ensuite, regardez ce que dit le fichier de verrouillage. La commande grep -A1 ‘magento/product-’ composer.lock affiche la version de base, et rien de plus. L’outil Commerce Version Tool lit composer.lock pour la version de base, puis teste chaque correctif à blanc sur l’arborescence. C’est un aveu discret : le fichier de verrouillage ne peut pas prouver qu’un correctif est présent.

Pourquoi un numéro de version ment

Il existe trois façons de se retrouver « à jour » sans être corrigé, et chacune échoue différemment.

La première est une mise à jour Composer. Adobe n’a publié aucun paquet Composer pour les correctifs de sécurité d’octobre et qualifie la livraison par correctif isolé seulement d’intentionnelle. BleepingComputer, citant Sansec, affirme qu’une simple installation Composer ne suffit pas, et que BlockStrap et StyleSmuggler sont deux correctifs distincts qui doivent tous deux être en place. Une équipe qui lance composer update en octobre peut avoir fait avancer la version de base sans jamais corriger la faille.

La deuxième est le correctif isolé, qui a ses règles. Vous devez déjà être sur la dernière version -p de sécurité de votre ligne, et chaque correctif isolé mensuel antérieur doit déjà être appliqué, dans l’ordre des publications. Chaque ZIP mensuel contient d’abord le fichier CE, puis EE s’il existe, puis B2B. L’exemple du KB pour la 2.4.6-p15 est un fichier nommé 246p15-2026-09-001-CE. Si vous sautez un mois, vous appliquez le fichier d’octobre à une arborescence qu’Adobe n’a pas testée.

La troisième est Adobe Commerce Cloud. Adobe met en garde contre l’application du correctif isolé lorsque la même correction est déjà arrivée par cloud-patches, parce que le KB dit que cela peut provoquer des échecs d’installation. Ici, le piège est la double application, pas l’omission. L’erreur consiste à corriger plus fort.

Gardez aussi en tête le correctif de septembre. La CVE-2026-75650, la faille StyleSmuggler qu’Adobe décrit comme exploitée dans la nature, est corrigée par le correctif VULN-39341, et le ZIP d’octobre ne le contient pas. Une boutique qui a pris les fichiers d’octobre sans le correctif de septembre a fermé une porte et laissé l’autre ouverte.

Vérifier avec patch-status, puis s’en méfier

La vérification recommandée par Adobe est le Commerce Version Tool, lancé avec php vendor/bin/patch-status. Il liste les correctifs appliqués et manquants, et donne un statut par CVE : PROTECTED, VULNERABLE ou UNKNOWN. Trois éléments compliquent la chose.

D’abord, l’outil lui-même est livré dans le correctif isolé de juillet 2026. Si vendor/bin/patch-status n’existe pas, il faut d’abord appliquer le correctif de juillet, donc un correctif plus ancien est nécessaire pour vérifier un plus récent. Testez cela avant tout le reste :

test -f vendor/bin/patch-status && echo present || echo absent

Ensuite, UNKNOWN n’est pas un succès. L’outil marque un correctif comme inconnu lorsqu’il ne peut pas confirmer sa présence, et sa documentation décrit le résultat comme informatif. Traitez UNKNOWN comme VULNERABLE tant que quelqu’un n’a pas ouvert le fichier corrigé et vu la modification.

Enfin, l’outil exige PHP 8.1 ou plus récent et le binaire patch du système. Vérifiez les deux avant de vous fier à son rapport.

php vendor/bin/patch-status | grep -E 'CVE-2026-103849|CVE-2026-92909|CVE-2026-92464'

Cherchez les trois CVE, pas seulement BlockStrap. Le bulletin en liste neuf autres. La CVE-2026-92909 est notée 9,8, ne demande aucune authentification et permet l’exécution de code arbitraire dans B2B. La CVE-2026-92464 est notée 9,1, exige des privilèges et permet elle aussi l’exécution de code arbitraire. Une boutique qui corrige BlockStrap et rien d’autre a réglé le titre et laissé un second chemin d’exécution de code ouvert.

Sur Cloud, le correctif de septembre se vérifie plutôt avec le Quality Patches Tool : vendor/bin/magento-patches -n status | grep -E ‘39341|Status’. Cherchez le correctif 39341 dans cette sortie.

La vérification au niveau des fichiers est celle en laquelle j’ai le plus confiance, parce qu’elle ne dépend pas du jugement de l’outil. Un test à blanc inversé demande si le correctif s’applique à l’envers sur ce qui est sur le disque :

patch -p1 -R --dry-run < <fichier-de-correctif-d-octobre>

Si le test inversé réussit, les modifications du correctif sont présentes dans les fichiers. S’il échoue, le fichier est soit non corrigé, soit modifié depuis, et les deux situations méritent d’être connues. N’utilisez -p2 que si le KB le permet. Le test prouve que les octets correspondent, pas qui les a mis là.

Terminal affichant des indicateurs de statut de correctifs sur un bureau de développeur

Chasser le code qui a déjà tourné

Je dois être franc. Aucune des sources publiques que j’ai pu consulter ne donne de noms de fichiers, d’empreintes ou de motifs de journaux pour BlockStrap. Les indicateurs que j’ai trouvés appartiennent à d’autres campagnes, StyleSmuggler et PolyShell, et je ne les transposerais pas sur BlockStrap. Ce qui suit est une chasse générique, construite à partir du mécanisme que décrit BleepingComputer : une donnée contrôlée par l’attaquant, dans un gabarit de courriel enfant, est signée puis réanalysée au niveau racine, où une directive de bloc introduite en douce s’exécute dans le moteur de rendu de Magento.

Commencez par le PHP là où il n’a rien à faire. La commande find pub/media -type f -iname ‘*.php’ -print ne devrait rien retourner. Les répertoires médias contiennent des images, donc tout fichier PHP qui s’y trouve est une constatation à trier, pas du bruit à filtrer.

Ensuite, regardez ce qui a changé. Les déploiements réécrivent les horodatages, donc les recherches par date de modification sont bruyantes par nature. Comparez les résultats au journal de déploiement plutôt que de faire confiance à un find nu :

find . -type f -name '*.php' -newermt '2026-09-01' -not -path './var/*' -not -path './generated/*' -print > php-modifies-depuis-sep.txt

J’ai exclu var et generated parce que votre pipeline les reconstruit à chaque déploiement. Confirmez-le dans votre configuration avant de faire confiance à cette exclusion, et vérifiez pub/static séparément.

Les gabarits de courriel sont l’endroit le plus direct où le mécanisme touche le système. Les gabarits de courriel Magento légitimes utilisent aussi des directives de bloc, donc une correspondance est une question, pas une alarme. Comparez avec un export de référence :

SELECT template_id, template_code, added_at FROM email_template WHERE template_text LIKE '%{{block%';

Tout gabarit que vous ne reconnaissez pas, ou toute modification d’un gabarit que vous avez écrit, va dans le billet. Cette requête est une déduction tirée du mécanisme, pas un indicateur publié.

Vérifiez ensuite les comptes administrateurs, peu coûteux à interroger et coûteux à manquer :

SELECT user_id, username, created, logdate FROM admin_user ORDER BY created DESC;

Un nouveau compte créé pendant la fenêtre, ou une connexion un jour où personne ne travaillait, est exactement ce qu’il faut écarter avant que le correctif ne ferme la porte.

Si vous ne pouvez pas exclure une altération, la clé de chiffrement est dans le périmètre. Elle se trouve dans app/etc/env.php et protège chaque identifiant que la boutique a chiffré avec elle. Le KB d’Adobe sur StyleSmuggler, APSB26-146, énumère une quinzaine d’étapes de rotation : mode maintenance, arrêt des tâches cron, rotation de la clé, mots de passe administrateurs, jetons d’intégration, secrets OAuth, clés de passerelle de paiement, identifiants de base de données et Fastly, clés SSH, clés des API d’expédition et de taxes. Le bulletin d’octobre ne dit rien sur la nécessité d’une rotation pour BlockStrap. Utilisez APSB26-146 comme liste d’inventaire, pas comme verdict sur le fait que vous avez été touché.

Corriger sans casser la vitrine

C’est là que les équipes prudentes perdent un après-midi. Les correctifs isolés modifient le code source PHP, mais la vitrine sert du code généré et des ressources statiques construits à partir de lui. Un correctif qui s’applique proprement peut quand même laisser un contenu périmé en ligne. Le préproduction, si vous en avez une, est généralement deux versions derrière la production et documentée dans un README qui dit de ne pas toucher. Réglez cela d’abord, parce qu’un test de correctif sur la mauvaise arborescence ne prouve rien. Voici ma séquence, qui est ma pratique et non l’ordre documenté par Adobe :

  1. Clonez la production vers la préproduction et prenez un instantané de la base de données et du code avant que le premier octet ne change.
  2. Testez chaque correctif à blanc avec patch -p1 —dry-run < . Si un bloc échoue, essayez -p2 dans la mesure où le KB le permet, mais un bloc en échec est un arrêt, pas un haussement d’épaules.
  3. Appliquez dans l’ordre du KB : les ZIP mensuels antérieurs d’abord, CE avant EE avant B2B à l’intérieur de chacun. N’appliquez jamais un fichier que vous ne pouvez pas placer dans cette séquence.
  4. Videz les caches dans Admin, sous Système > Gestion du cache, puis reconstruisez le code généré et le contenu statique avec votre pipeline habituel. Ne faites pas confiance à une sortie produite avant le correctif.
  5. Relancez patch-status et le test inversé en production, puis analysez la vitrine depuis l’extérieur.

Deux règles à coller au-dessus de chaque script de déploiement. Ne jamais ajouter || true à une étape de correctif, parce que le bloc que vous cachez est celui qui reste non corrigé. Et ne jamais empiler le correctif isolé sur cloud-patches. Chaque règle coûte quelques secondes à suivre et un week-end à apprendre.

Salle de serveurs froide avec des rangées de serveurs en baie et un ordinateur portable affichant une comparaison de code

La priorité 2 est un calendrier, pas une note de risque

Adobe classe BlockStrap en priorité 2, ce qui, dans son système, signifie un correctif dans une fenêtre de 30 jours. Sansec conteste cette cote. BleepingComputer rapporte l’argument de Sansec selon lequel StyleSmuggler est passé de la priorité 1 à une exploitation massive en trois jours, et que quatre chemins d’attaque contre BlockStrap ont été identifiés en moins de 24 heures. Adobe affirme ne connaître aucune exploitation dans la nature pour les problèmes du bulletin. Les deux peuvent être vrais en même temps, et c’est là le problème.

Mon point de vue : un champ de priorité décrit le calendrier de déploiement du fournisseur, pas votre exposition. Votre exposition dépend de la question de savoir si la vitrine répond à Internet et si la faille exige une connexion. BlockStrap a un score de base CVSS 3.1 de 10,0, ne demande aucun privilège et aucune interaction de l’utilisateur, et le vecteur inclut un changement de portée, S:C. Pour une vitrine publique, c’est un correctif de cette semaine, quelle que soit l’étiquette à côté. La priorité 2 est ce qu’Adobe peut promettre à l’ensemble de sa clientèle. Ce n’est pas ce qu’une seule boutique devrait accepter.

Sansec affirme qu’il publiera une mise à jour s’il détecte des vagues d’attaques massives. Abonnez-vous à ce fil dès maintenant. C’est le signal que vous recevrez le plus probablement en premier, et c’est celui qui vous dira si la cote de priorité était fausse.

Où les sources publiques s’arrêtent

Je n’ai pas pu ouvrir la page complète de Sansec sur BlockStrap. Sa FAQ et ses sections d’indicateurs ne se sont pas affichées, donc chaque affirmation de Sansec ici passe par BleepingComputer. Je n’ai pas non plus pu vérifier les commandes de build et de déploiement Magento sur les pages d’Adobe, et c’est pourquoi la séquence ci-dessus est ma pratique et non une consigne du fournisseur. Les indicateurs de compromission de BlockStrap restent non publiés à ma connaissance. Le runbook honnête repose sur la vérification, une chasse générique et un ordre de correctifs que vous pouvez défendre, et il devra être mis à jour quand les détails de Sansec ou les indicateurs d’Adobe seront disponibles.

Le saviez-vous

  • BlockStrap est classé CWE-1336, neutralisation dans les moteurs de gabarits, et le bulletin crédite le chercheur vozec.
  • Le bulletin liste neuf autres CVE aux côtés de BlockStrap, dont deux permettant l’exécution de code arbitraire.
  • Le Commerce Version Tool n’est livré que dans le correctif isolé de juillet 2026, donc vérifier le correctif d’octobre dépend d’un correctif datant de trois mois plus tôt.
  • Le ZIP d’octobre ne contient pas le correctif de septembre pour StyleSmuggler, VULN-39341. Les deux correctifs sont distincts.
  • Le KB d’Adobe indique que les téléchargements pour la 2.4.6 et les versions antérieures exigent des clés Composer, tandis que les téléchargements Open Source ne sont offerts qu’à partir de la 2.4.7.

Sources

À lire aussi