PolyShell CVE-2026-48356 : vérifier et corriger Magento

PolyShell : ce qui est établi, ce qui diverge

Ce que disent les sources, et ce que vous en retenez

Faites défiler le tableau

Pourquoi le correctif ne clôt pas le dossier

Ce que cette procédure vous laisse en main

• Un inventaire par boutique — édition (Commerce ou Open Source), version exacte, présence ou absence du correctif 2026-jul.
• Une version cible par branche — lue dans le bulletin APSB26-73, sans deviner la numérotation.
• Un état figé avant intervention — snapshot et export de base conservés comme pièce, avant tout nettoyage.
• Quatre contrôles reproductibles — fichiers sous pub/media, portes dérobées accesson.php, JavaScript dans cms_block et dans cms_page.
• Une rotation complète des accès — comptes admin, clés API et d'intégration, base de données, clé de chiffrement, SSH et SFTP.
• Un état daté pour chaque client — ce qui a été vérifié, trouvé, corrigé, et ce qui ne l'a pas été.

Versions affectées et versions corrigées selon APSB26-73

Faites défiler le tableau

Inventorier la version de chaque boutique

1. 01

   Lire la version déclarée

   cd /var/www/boutique-client
bin/magento --version
   La commande affiche l'édition et le numéro. Le chemin est un exemple : adaptez-le à chaque hébergement. Lancez-la avec l'utilisateur système propriétaire des fichiers, pas en root, pour ne pas modifier les droits du cache.

2. 02

   Recouper avec Composer

   composer show magento/product-community-edition
   pour Magento Open Source, ou
   composer show magento/product-enterprise-edition
   pour Adobe Commerce. Composer lit ce qui est réellement installé. Si les deux lectures divergent, c'est Composer qui fait foi, et l'écart se note.

3. 03

   Balayer un serveur entier

   find /var/www /home -name composer.lock -not -path '*/vendor/*' -exec grep -H -A1 '"name": "magento/product-' {} +
   Chaque fichier cité appartient à une installation Magento, et la ligne version suit le nom du paquet. Une préproduction publique ou une ancienne copie décompressée compte comme une boutique : elle est exposée de la même façon si elle est servie.

4. 04

   Classer avec le tableau des versions

   Comparez le numéro relevé au tableau ci-dessus. Règle de lecture : toute version qui ne porte pas le suffixe 2026-jul de sa branche est à traiter. Pour Magento Open Source 2.4.5 et 2.4.4, absentes de la liste NVD, n'écrivez pas « non concernée » : renvoyez au bulletin Adobe et traitez la boutique comme exposée tant que vous n'avez pas lu le contraire.

5. 05

   Consigner une ligne par boutique

   Client, serveur, chemin, édition, version relevée, date et heure du relevé. Ajoutez dès maintenant les colonnes qui serviront plus loin : correctif appliqué, résultat des quatre contrôles, accès tournés. Ce tableau devient la pièce centrale du dossier remis au client.

Figer l'état avant de toucher : c'est aussi une preuve

Appliquer le correctif sans coupure longue

1. 06

   Répéter sur une préproduction

   Restaurez l'état figé sur une préproduction, ou clonez la boutique, et jouez la mise à jour là d'abord. Chronométrez chaque commande : c'est cette durée qui fixe la fenêtre de maintenance à annoncer au client.

2. 07

   Fixer la version corrigée

   composer require magento/product-community-edition=<version-corrigée> --no-update
   Remplacez le paquet par magento/product-enterprise-edition pour Adobe Commerce, et <version-corrigée> par la version au suffixe 2026-jul de votre branche, telle que l'écrit le bulletin.

3. 08

   Résoudre et valider le verrou

   composer update magento/product-community-edition --with-all-dependencies
   Relisez la liste des paquets modifiés. Le composer.lock obtenu et testé est celui que vous déploierez : la production ne résout plus rien, elle installe.

4. 09

   Ouvrir la fenêtre de maintenance en production

   bin/magento maintenance:enable
bin/magento maintenance:allow-ips <votre-ip>
   Tout ce qui précède s'est fait sans couper la vente. La seconde commande vous laisse tester la boutique avant sa réouverture.

5. 10

   Installer et appliquer

   composer install --no-dev
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento setup:static-content:deploy
   Avec un verrou déjà validé, la coupure se limite à ces quatre commandes.

6. 11

   Rouvrir et contrôler

   bin/magento maintenance:disable
composer show magento/product-community-edition
   La version installée doit être la version corrigée de votre branche. Passez une commande avec la passerelle de paiement en mode test, puis reportez la version et l'heure dans le tableau.

Chercher les traces de compromission

1. 12

   Lister les fichiers déposés sous pub/media

   find pub/media/custom_options/ pub/media/customer_address/ -type f ! -name '.htaccess'
   Commande publiée par Sansec, à lancer depuis la racine de la boutique. Tout fichier listé est à examiner, en particulier un script PHP. Copiez-le hors de l'arborescence publique avec sa date de modification avant de le supprimer.

2. 13

   Chercher les portes dérobées accesson.php

   find . -name 'accesson.php' -type f
   Sansec signale ce fichier « dans plusieurs répertoires » : lancez la recherche depuis la racine, pas seulement sous pub/. Un résultat vide prouve l'absence de ce fichier-là, pas l'absence de toute porte dérobée.

3. 14

   Interroger la table cms_block

   SELECT block_id, identifier, update_time FROM cms_block WHERE content LIKE '%fpCode%' OR content LIKE '%se_referrer%' OR content LIKE '%localStorage.getItem%';
   Requête publiée par Sansec. Ajoutez le préfixe de table de l'installation s'il en existe un. La colonne update_time aide à dater l'injection.

4. 15

   Interroger la table cms_page

   SELECT page_id, identifier, update_time FROM cms_page WHERE content LIKE '%fpCode%' OR content LIKE '%se_referrer%' OR content LIKE '%localStorage.getItem%';
   Même contrôle sur les pages CMS. Un résultat n'est pas forcément malveillant : localStorage.getItem peut figurer dans un script légitime. Lisez le contenu avant de conclure.

5. 16

   Rapprocher des indicateurs publiés

   Pour la vague de mars 2026, Sansec a publié un domaine de chargeur, lanhd6549tdhse.top, une clé localStorage, 136c1e07507f4a97, et une balise de porte dérobée, 8194460. Cherchez-les dans les résultats précédents et dans les fichiers trouvés, par exemple avec grep -rl 'lanhd6549tdhse' pub/ app/. Cette liste n'est pas exhaustive : son absence ne blanchit pas une boutique.

6. 17

   Contrôler les comptes administrateurs

   SELECT user_id, username, email, created, logdate, is_active FROM admin_user ORDER BY created DESC;
   Un compte que personne ne reconnaît, ou créé à une date proche d'un fichier suspect, se désactive puis se documente. Le contrôle mensuel de ces points sur chaque VPS client est décrit dans notre checklist d'audit.

Dépannage : les blocages fréquents pendant la procédure

Après le nettoyage : ce qui doit tourner

• Mots de passe administrateur — tous les comptes de admin_user, y compris ceux que vous jugez sains.
• Clés API et intégrations — jetons des intégrations déclarées dans l'administration, clés des services tiers (paiement, transport, ERP) stockées dans la configuration.
• Identifiants de base de données — nouveau mot de passe, reporté dans la configuration de la boutique.
• Clé de chiffrement — à changer en suivant la documentation Adobe, après avoir mesuré l'effet sur les données déjà chiffrées.
• Accès SSH et SFTP — mots de passe, clés SSH autorisées, comptes système inconnus.
• Accès d'hébergement — panneau de contrôle et sauvegardes, qui donnent eux aussi accès aux fichiers.

L'état daté à remettre à chaque client

Faites défiler le tableau

Ce que vous gardez, et les sources à citer