CVE-2026-75650 Adobe Commerce / Magento 2.4.4-2.4.9 : RCE 10.0 au CISA KEV

CVE-2026-75650 est notée CVSS 10.0 et a été ajoutée au catalogue CISA KEV le 8 septembre 2026, le lendemain de sa publication, avec une échéance de remédiation à trois jours. Elle affecte Adobe Commerce, Adobe Commerce B2B et Magento Open Source.

C'est une injection dans le moteur de templates aboutissant à une exécution de code arbitraire, sans authentification et sans interaction de l'utilisateur.

Pour une boutique en ligne, la conséquence dépasse la compromission serveur habituelle : une exécution de code sur un Magento donne accès au flux de paiement, et c'est exactement ce que les groupes de skimming (Magecart) recherchent depuis dix ans.

La vulnérabilité

Description Adobe :

Adobe Commerce is affected by an Improper Neutralization of Special Elements Used in a Template Engine vulnerability that could result in arbitrary code execution in the context of the current user. An attacker could exploit this vulnerability to execute arbitrary code. Exploitation of this issue does not require user interaction. Scope is changed.

Le S:C (scope changed) est ce qui porte le score à 10.0 : l'exécution déborde du composant vulnérable. Sur une plateforme e-commerce, cela se traduit concrètement — le moteur de templates rend les pages vues par les clients, donc le code injecté s'exécute dans le contexte qui sert le tunnel de commande.

Pourquoi les moteurs de templates sont une cible récurrente

Un moteur de templates existe pour évaluer des expressions dans du contenu. C'est sa fonction. La sécurité repose donc entièrement sur la frontière entre « ce que le développeur a écrit » et « ce que l'utilisateur a fourni ».

Sur Magento, cette frontière est traversée par beaucoup de chemins légitimes : contenu CMS, blocs statiques, modèles d'email transactionnel, règles de prix, attributs produit. Chacun est une occasion pour une donnée contrôlée par l'attaquant d'arriver dans un contexte où elle sera évaluée plutôt qu'affichée.

Adobe ne détaille pas le point d'entrée exact — je ne vais pas le deviner. Mais le vecteur PR:N/UI:N dit l'essentiel : le chemin est atteignable depuis l'extérieur, sans compte.

Versions affectées

⚠️ Ce sont les bornes de versions affectées publiées par NVD, pas les versions corrigées. Adobe distribue le correctif sous forme de patch de sécurité par branche : récupère le numéro applicable à ta version exacte sur le bulletin Adobe correspondant. Je ne vais pas inventer un numéro de version cible.

La plage couvre toute la ligne 2.4, donc en pratique : si tu es sur Magento 2.4 et que tu n'as pas appliqué de patch de sécurité en septembre 2026, considère que tu es concerné.

Vérifier ta version :

php bin/magento --version

# Patchs de sécurité déjà appliqués
composer show magento/product-community-edition
composer show | grep -i "magento/module-.*patch"

Ce qui est réellement en jeu

Le vol de données de carte bancaire

C'est le débouché principal, et il ne dépend pas de savoir si tu stockes les numéros de carte — tu ne les stockes probablement pas, et ça ne change rien.

Un attaquant qui exécute du code sur le serveur modifie les templates rendus côté client pour y injecter un script qui capture les champs du formulaire de paiement avant qu'ils partent vers le prestataire. Le paiement fonctionne normalement, le client ne voit rien, le prestataire ne voit rien d'anormal. C'est le fonctionnement de Magecart depuis 2015, et Magento en est la cible historique.

La conformité PCI-DSS est directement engagée, y compris pour les marchands en SAQ-A qui pensent avoir externalisé le risque : si ta page héberge le formulaire, même en iframe détournable, tu es dans le périmètre.

Les données clients

Adresses, historiques de commandes, emails, téléphones. Une violation de données personnelles au sens du RGPD, avec obligation de notification sous 72 heures.

La persistance

Magento est une plateforme riche en mécanismes d'extension. Un attaquant dispose de nombreux emplacements discrets pour se réinstaller : blocs CMS contenant du code, modules injectés, tâches planifiées, modèles d'email modifiés, entrées dans core_config_data. Un nettoyage partiel laisse presque toujours quelque chose.

Détection

Intégrité du code

C'est le contrôle le plus fiable, parce que l'attaquant doit écrire quelque part.

# Fichiers modifiés récemment hors répertoires volatils
find /var/www/magento -type f -newermt "-30 days" \
  -not -path "*/var/*" -not -path "*/generated/*" \
  -not -path "*/pub/static/*" -not -path "*/vendor/*" \
  -ls | head -50

# Comparaison avec les paquets Composer d'origine
composer install --dry-run 2>&1 | grep -i modif
git status --porcelain   # si le déploiement est versionné

Blocs CMS et templates

Le stockage en base est l'endroit préféré des skimmers, parce qu'il survit à un redéploiement du code :

-- Blocs et pages CMS contenant du script
SELECT block_id, identifier, update_time FROM cms_block
  WHERE content LIKE '%<script%' OR content LIKE '%eval(%'
  OR content LIKE '%base64_decode%';

SELECT page_id, identifier, update_time FROM cms_page
  WHERE content LIKE '%<script%' OR content LIKE '%atob(%';

-- Configuration modifiée récemment — y compris en-têtes et scripts injectés
SELECT path, value, updated_at FROM core_config_data
  ORDER BY updated_at DESC LIMIT 40;

Comptes et tâches

-- Comptes administrateurs, en particulier créés hors de tes flux
SELECT user_id, username, email, created, logdate FROM admin_user
  ORDER BY created DESC;

Vérifie aussi les tâches planifiées système (crontab -l pour l'utilisateur web) et les modules installés que personne ne reconnaît.

Côté client — le contrôle décisif

Charge une page de paiement dans un navigateur et inspecte les requêtes réseau sortantes. Tout domaine qui n'est pas ton prestataire de paiement déclaré est un problème. C'est le test le plus direct pour détecter un skimmer actif, et il ne demande aucun accès serveur.

Mitigation

1. Appliquer le patch Adobe — immédiat

L'échéance CISA était le 11 septembre. Avec un 10.0, aucune authentification, aucune interaction et une exploitation confirmée, c'est une intervention hors fenêtre.

2. Mesures de réduction en attendant

• WAF devant la boutique : cela ne corrige rien mais peut filtrer une partie des charges utiles connues
• Interface d'administration restreinte par IP et sur une URL non devinable — même si cette CVE n'en a pas besoin, c'est la surface qui compte pour les prochaines
• Content-Security-Policy sur les pages de paiement : une CSP stricte limitant les domaines de destination est la contre-mesure la plus efficace contre l'exfiltration par skimmer, y compris quand le serveur est compromis

3. Si tu conclus à une compromission

L'ordre compte, et le nettoyage à chaud est déconseillé.

1. Traite l'incident comme une violation de données de paiement dès le départ — préviens ton prestataire et ton acquéreur, les obligations PCI-DSS se déclenchent
2. Redéploie le code depuis une source de confiance (dépôt Git + Composer), n'essaie pas de nettoyer les fichiers en place
3. Audite la base : blocs CMS, core_config_data, comptes admin, modèles d'email — le code propre ne sert à rien si le skimmer est stocké en base
4. Fais tourner tous les secrets : clés API du prestataire de paiement, identifiants base, env.php, clés de chiffrement, mots de passe administrateurs
5. Force la réinitialisation des mots de passe clients et invalide les sessions
6. Notifie si des données personnelles ont pu être exposées — RGPD, 72 heures

Pourquoi surveiller en continu votre plateforme e-commerce

Magento reçoit des patchs de sécurité plusieurs fois par an, et les délais d'application se comptent régulièrement en mois — parce qu'une mise à jour touche un site qui génère du chiffre d'affaires en continu, avec des extensions tierces dont la compatibilité doit être validée. Pendant ce temps, les opérateurs de skimming scannent en permanence : Magento est leur cible la mieux documentée.

Avec cveo.tech, inventorie ta plateforme e-commerce et ses composants avec leur version exacte, et reçois une alerte automatique dès qu'une CVE critique en concerne un — pour que le délai entre le bulletin Adobe et ta décision se compte en heures et non en semaines.