Adobe Commerce et AEM : CVE-2026-100133 et 106629, deux XSS stockées notées 9.3

Le 13 octobre 2026, NVD a publié deux CVE Adobe à la même description, à un produit près : CVE-2026-100133 sur Adobe Commerce et CVE-2026-106629 sur Adobe Experience Manager (AEM). Deux XSS stockées, notées 9.3.

Une XSS en CRITICAL, ça surprend. C'est justement la partie intéressante.

Aucune n'est au CISA KEV à la date de rédaction.

Ce que font les failles

Adobe Commerce is affected by a stored Cross-Site Scripting (XSS) vulnerability that could be abused by an attacker to inject malicious scripts into vulnerable form fields. [...] Scope is changed.

Un attaquant dépose du JavaScript dans un champ de formulaire vulnérable. Le script est stocké, puis exécuté dans le navigateur de chaque personne qui affiche la page concernée. Adobe évoque une prise de contrôle du compte ou de la session de la victime, avec un accès potentiellement élevé.

Pourquoi une XSS atteint 9.3

La plupart des XSS se situent entre 5 et 7. Trois éléments du vecteur font monter celles-ci :

• PR:N : aucun compte n'est nécessaire pour déposer le script. Sur une boutique ou un site public, des formulaires accessibles à tous existent forcément.
• S:C : le code s'exécute dans le navigateur de la victime, donc hors du composant vulnérable. C'est le changement de portée — et c'est ce qui fait le plus grimper le score.
• C:H/I:H : Adobe considère que l'impact sur la confidentialité et l'intégrité est élevé, pas limité. Ce choix suggère que les victimes visées peuvent être des utilisateurs privilégiés.

Ce dernier point est le scénario qui inquiète. Une XSS stockée depuis un formulaire public qui s'exécute quand un administrateur ouvre la page dans le back-office, c'est une session admin entre les mains de l'attaquant. Sur Commerce, cela veut dire catalogue, commandes, données clients et configuration du paiement. Sur AEM, contenu publié et comptes d'auteurs.

Le seul frein est UI:R : il faut que quelqu'un consulte la page. Sur un back-office utilisé tous les jours, ce n'est pas un frein sérieux.

Versions

NVD ne publie ni versions affectées ni version corrigée pour ces deux CVE à la date de rédaction. Reporte-toi aux bulletins de sécurité Adobe d'octobre pour Commerce et pour AEM — je n'invente pas de numéro de version.

Pour le contexte des failles Adobe du mois précédent, dont une Magento au KEV, voir le point Adobe de septembre 2026.

Détection

• Contenu HTML ou JavaScript inattendu stocké dans des champs de formulaire (avis, adresses, messages, champs de profil, contenu AEM)
• Sessions administrateur utilisées depuis une adresse IP ou un navigateur inhabituel
• Actions d'administration non attribuables à une personne : nouveaux comptes admin, modification des moyens de paiement, ajout de scripts dans les thèmes ou les templates
• Requêtes sortantes depuis les navigateurs des administrateurs vers des domaines inconnus, si ton proxy les journalise

Mitigation

1. Appliquer les correctifs Adobe pour Commerce et AEM dès que tu as identifié la version correspondante dans les bulletins.
2. Renforcer la Content Security Policy du back-office et du site : sans source de script autorisée, un script injecté a beaucoup moins de marge.
3. Séparer le back-office : accès restreint par IP ou VPN, et navigation dédiée pour les administrateurs.
4. Rechercher les contenus déjà stockés suspects dans les champs alimentés par des utilisateurs, et les purger.
5. En cas de doute : invalider les sessions administrateur, faire tourner les mots de passe et les jetons d'intégration, et auditer les modifications récentes de configuration.

Pourquoi surveiller vos plateformes e-commerce et CMS

Une XSS stockée n'a pas l'air grave jusqu'à ce qu'elle s'exécute dans la bonne session. Sur une plateforme qui gère paiements et données clients, la bonne session, c'est celle de l'administrateur.

Avec cveo.tech, inventorie tes instances Commerce et AEM avec leur version exacte, et reçois une alerte dès qu'une CVE critique les concerne.