9 min de lecture - Faille zero-day Adobe Commerce : prouvez le correctif et renouvelez les accès

Adobe a mis à jour ses consignes d’urgence pour Commerce le 9 septembre 2026, au lendemain de la publication d’un correctif. L’entreprise indique que CVE-2026-75650 a été exploitée contre des marchands Adobe Commerce. Elle demande aux exploitants concernés d’appliquer le correctif correspondant à leur version, puis de renouveler la clé de chiffrement et les identifiants que cette clé a pu protéger.

Cette deuxième action change la décision de gestion. Un déploiement au vert ne clôt pas le travail si un attaquant a pu lire un accès au paiement, un jeton d’intégration ou une clé de déploiement avant le correctif.

Le tableau ci-dessous s’adresse aux exploitants, aux agences et aux responsables techniques d’une installation Adobe Commerce ou Magento Open Source. Cette méthode proposée ne rapporte aucun cas client d’Exceev et ne remplace ni l’assistance d’Adobe ni une réponse à incident qualifiée.

Traitez le correctif comme un changement d’incident

Le bulletin de sécurité APSB26-146 d’Adobe classe la vulnérabilité au niveau critique, avec un score CVSS de base de 10,0. Il indique qu’un attaquant non authentifié peut exploiter une neutralisation incorrecte dans un moteur de modèles pour exécuter du code arbitraire. Adobe répertorie Adobe Commerce 2.4.4 à 2.4.9, plusieurs branches B2B et Magento Open Source 2.4.6 à 2.4.9. Notez la version exacte et son correctif : « Magento 2 » ne suffit pas pour autoriser l’intervention.

Le calendrier impose une gestion d’incident. Le CERT-FR a publié son avis le 8 septembre et confirme une exécution de code arbitraire à distance ainsi que l’exploitation active signalée par Adobe. Le Centre canadien pour la cybersécurité a aussi indiqué le 8 septembre que la CISA avait ajouté CVE-2026-75650 à son catalogue des vulnérabilités exploitées. Aucun de ces avis ne prouve la compromission d’une boutique. Ils écartent toutefois l’attente d’une fenêtre ordinaire au seul motif qu’aucune alerte ne s’est déclenchée.

Organisez la réponse autour de quatre chantiers liés :

Un responsable unique doit garder ces relevés cohérents. Sans chronologie commune, l’équipe peut clôturer le correctif alors qu’un ancien accès au prestataire de paiement reste valide.

Faites correspondre le correctif à la version exécutée

Commencez par la version qui traite le trafic. Notez le produit, sa version complète, l’hébergement et le module B2B avant toute modification. Plusieurs boutiques sur une même infrastructure n’ont pas forcément le même état.

Les consignes Adobe du 8 septembre associent chaque version à une archive VULN-39341. Consultez le tableau en ligne au lieu de recopier un nom depuis une discussion. Il couvre Commerce on Cloud, les installations sur site et Magento Open Source, avec des méthodes qui dépendent de l’environnement.

Lorsque la situation le permet, testez le correctif hors production sur les paiements, commandes, messages transactionnels et tâches planifiées propres à la boutique. Notez toute lacune acceptée et la surveillance prévue après le déploiement.

Sur Commerce on Cloud, Adobe documente un contrôle avec Quality Patches Tool et la commande magento-patches. Conservez la sortie qui indique VULN-39341 comme appliqué. Ailleurs, gardez une preuve équivalente : un pipeline terminé ou un fichier copié ne prouve pas l’état de l’application exécutée.

Renouvelez les identifiants auprès de leur émetteur

La consigne d’Adobe est précise : la rotation de la seule clé de chiffrement Commerce n’invalide pas les identifiants qu’un attaquant a pu lire. L’entreprise demande aux marchands de les renouveler aussi auprès du prestataire de paiement ou de tout autre système qui les a émis.

Partez de la configuration et du registre des intégrations, pas de mémoire. Adobe cite les mots de passe d’administration, les jetons REST, SOAP et GraphQL, les secrets OAuth, les accès au paiement et à la base de données, les clés SSH ou de déploiement, les comptes privilégiés et les clés API des extensions. Chaque boutique doit compléter cette liste selon ses services.

Ordonnancez les changements selon leurs dépendances. Une rotation de base de données mal synchronisée peut arrêter la boutique. Une clé modifiée localement mais encore valide chez le prestataire reste exploitable. Pour chaque secret, notez l’émetteur, le compte, le privilège, l’heure d’activation et la preuve que l’ancien accès ne s’authentifie plus.

Ne copiez aucun secret dans le tableau de réponse. Conservez-y les références, les responsables et l’état, puis gardez les valeurs dans le gestionnaire prévu. Masquez aussi les sorties de commande jointes aux tickets.

Adobe place le correctif avant le mode maintenance, le renouvellement, la purge du cache et le retour en service. Suivez sa procédure à jour et décidez quand suspendre paiements, tâches et intégrations pour éviter des reprises en double ou incomplètes.

Analysez la période antérieure au correctif

La recherche de l’équipe Sansec Forensics nomme la campagne StyleSmuggler et situe sa première exploitation confirmée au 4 septembre. Sansec indique avoir reproduit la chaîne sans authentification sur des installations propres de Magento Open Source 2.4.7, 2.4.8 et 2.4.9. Son rapport évolutif décrit aussi plusieurs noms de processus, fichiers et indicateurs réseau observés.

Utilisez ces indicateurs comme des pistes, jamais comme un certificat d’absence de compromission. L’enquête évoluait encore le 9 septembre et les charges observées ne couvrent pas tous les attaquants. L’absence d’un processus ou d’une adresse répertoriés ne prouve donc pas qu’une boutique est restée intacte.

Construisez la période d’exposition entre le dernier état sain connu et le correctif vérifié. Examinez proxy, CDN, journaux web et applicatifs, processus, tâches, fichiers, connexions sortantes, comptes d’administration et jetons. Préservez les horodatages et copies avant de modifier un composant suspect.

La publication NIST SP 800-61 révision 3 intègre la réponse à incident à la gestion du risque cyber. Elle n’analyse pas CVE-2026-75650, mais étaye le regroupement du correctif, de l’enquête et des preuves de reprise dans une même réponse.

Si l’analyse détecte une exécution ou une persistance non autorisée, appliquez le processus d’incident de l’organisation. Ce texte ne peut fixer le périmètre forensique, les obligations de notification ni le point de reprise d’un marchand. Ces décisions reviennent aux personnes qui connaissent le système, les contrats et le droit applicable.

Protégez le parcours métier pendant la reprise

Un incident Commerce touche les clients par des paiements interrompus, des commandes retardées ou des intégrations modifiées. Avant de renouveler les accès, l’équipe technique a besoin d’une courte carte métier :

• Quelles connexions de paiement, de traitement des commandes, de fiscalité ou de service client risquent de s’arrêter ?
• Quelles tâches en attente peuvent redémarrer, et comment détecterez-vous les doublons ?
• Quelles fonctions de la boutique peuvent rester disponibles sans l’intégration concernée ?
• Qui peut autoriser le mode maintenance et le retour au trafic normal ?
• Quelles communications avec les clients ou les partenaires doivent recevoir l’accord du responsable d’incident et une revue juridique ?

Après chaque changement à fort impact, utilisez quelques transactions fictives pour vérifier la commande, le prestataire appelé et le résultat, sans données client réelles. Rapprochez un échantillon chez le prestataire plutôt que de vous fier à la seule page de confirmation.

Surveillez ensuite les parcours modifiés. Des échecs d’authentification peuvent révéler un consommateur oublié de l’ancien identifiant, mais restaurer ce secret pour arrêter les alertes annulerait la révocation. Attribuez chaque échec à une personne qui peut mettre à jour ou retirer l’appelant.

Notre article sur la vérification de la chaîne de confiance après l’exploitation d’un serveur explique pourquoi l’état du correctif et les preuves de reprise répondent à des questions différentes. Cette distinction vaut ici, même si les produits, les attaquants et les parcours observés après exploitation n’ont aucun lien.

Clôturez avec des preuves, pas avec un ticket au vert

Avant de fermer le chantier, rassemblez un dossier lisible sans reconstruire les échanges. Identifiez les actifs, versions, preuve du correctif, période d’exposition, limites de l’enquête, accès renouvelés, contrôles de révocation, tests de reprise et surveillance restante.

Consignez clairement les lacunes. Une durée de conservation insuffisante du CDN, une extension sans responsable connu ou une intégration impossible à renouveler sans son fournisseur demandent une décision. Ces problèmes ne justifient pas de marquer la ligne comme terminée.

Après la reprise, attribuez chaque intégration à un responsable, répétez un correctif d’urgence sur l’hébergement utilisé et vérifiez la rétention des journaux. La prochaine alerte suivra alors une procédure connue.

Sources et limites

Nous avons ouvert et vérifié toutes les sources ci-dessous le 9 septembre 2026.

• Le bulletin de sécurité Adobe APSB26-146 établit la vulnérabilité, les branches concernées, la gravité, la condition d’authentification et le constat d’exploitation active.
• Les consignes urgentes d’Adobe, mises à jour le 9 septembre donnent le tableau des correctifs par version, la méthode de vérification et la séquence de renouvellement des accès.
• L’avis CERTFR-2026-AVI-1130 fournit l’alerte nationale française et renvoie vers le correctif Adobe.
• L’avis AV26-888 du Centre canadien pour la cybersécurité consigne séparément l’exploitation active et l’ajout au catalogue KEV de la CISA le 8 septembre.
• La recherche StyleSmuggler de Sansec fournit la chronologie de la campagne et les indicateurs techniques observés. Sansec vend aussi des services de sécurité Commerce et décrit une enquête en cours d’évolution.
• NIST SP 800-61 révision 3 étaye le cadre de gestion d’incident, sans évaluer cette CVE.

Les tableaux d’Adobe sur les versions et les correctifs peuvent évoluer. Les indicateurs de Sansec sont liés à une période et ne couvrent pas tout. Nous n’avons pas testé le correctif, examiné l’environnement d’un marchand ni confirmé la compromission d’une organisation. Vérifiez les consignes Adobe en ligne pour votre version exacte et faites appel à une réponse à incident qualifiée lorsque les preuves l’exigent.