En bref : la faille de sécurité Magento actuelle s'appelle PHP2Shell et ne se trouve pas dans Magento, mais dans PHP. Un correctif Magento ne la comble pas. Après la mise à jour de PHP avec redémarrage, vous devriez contrôler app/etc/env.php, la base de données à la recherche de skimmers et la liste des comptes admin.
Ce que PHP2Shell signifie pour les boutiques Magento
Magento Open Source et Adobe Commerce sont de grosses applications PHP qui fonctionnent le plus souvent avec PHP-FPM. Les failles CVE-2026-109618 et CVE-2026-109619 permettent, selon l'équipe PHP, d'exécuter du code malveillant sans authentification. Que la boutique elle-même soit à jour n'a aucune importance à cet égard.
Depuis des années, les boutiques Magento sont une cible privilégiée du skimming de cartes bancaires, où les saisies au paiement sont lues en cours de route. PHP2Shell ouvre une voie supplémentaire. Palo Alto Networks a dénombré plus de 22,6 millions d'instances PHP exposées et potentiellement vulnérables ; on ignore quelles boutiques en font partie.
Faille de sécurité Magento : déterminer correctement l'état de PHP
Magento n'affiche pas la version de PHP de manière visible dans l'administration. Vérifiez donc l'état dans le panneau d'hébergement pour le domaine ou faites-le confirmer par votre hébergeur. php -v en ligne de commande n'indique que le PHP CLI avec lequel fonctionnent bin/magento et les tâches cron. Le PHP web via FPM peut être une autre version, et les deux doivent être corrigés.
Les versions corrigées en amont sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35 ; les backports des distributions peuvent porter des numéros plus anciens. Les versions de PHP prises en charge par votre version de Magento se vérifient dans la configuration requise de la documentation d'Adobe (experienceleague.adobe.com). Pour Adobe Commerce sur l'infrastructure d'Adobe, demandez l'état à Adobe ou à votre exploitant. Vérifier correctement la version de PHP et l'état du correctif propose un guide pas à pas.
Où se trouve le code malveillant dans Magento
| Emplacement | Contenu | Point de contrôle |
|---|---|---|
app/etc/env.php |
Base de données, clé de chiffrement, chemin d'administration | Date de modification, renouveler les valeurs en cas de soupçon |
pub/ |
Racine web, pub/media, pub/static |
Fichiers PHP dans les dossiers media et static |
app/code/ |
modules propres | modules inconnus, fichiers modifiés |
vendor/ |
paquets Composer, extensions comprises | écarts par rapport au lockfile |
generated/, var/ |
code généré, cache, journaux | sauvegarder les journaux, régénérer le code |
| Base de données | configuration, blocs CMS, utilisateurs admin | scripts étrangers, nouveaux admins |
Dans Magento, les skimmers se trouvent souvent dans la base de données, par exemple dans les réglages pour des scripts supplémentaires dans l'en-tête ou le pied de page et dans les blocs CMS. Une simple analyse de fichiers les manque. Des accès en lecture sans danger aident pour un premier coup d'œil (préfixe de table selon l'installation) :
bin/magento info:adminuri
bin/magento module:status
SELECT username, email, created FROM admin_user;
SELECT path, value FROM core_config_data WHERE path LIKE 'design/%' AND value LIKE '%<script%';
Un paiement nettoyé ne signifie pas qu'aucune donnée n'a fui. Sauvegardez les journaux à partir du 20/10/2026 et les extractions de la base de données avant de supprimer des scripts. Ce n'est qu'ainsi qu'on pourra établir plus tard à partir de quand et quelles commandes ont été touchées.
Espace d'administration et extensions
Dans Magento, le chemin d'administration est librement choisi et figure dans env.php. Un chemin difficile à deviner est judicieux, mais ne remplace ni l'authentification à deux facteurs ni une restriction aux réseaux connus. Contrôlez régulièrement les utilisateurs admin et leurs rôles, de même que les intégrations et les jetons API.
Les extensions de tiers sont nombreuses dans Magento : moyens de paiement, connexions ERP, modules de recherche et de marketing. Chacune apporte du code qui doit être vérifié lors des mises à niveau de PHP. Utilisez régulièrement composer audit et supprimez entièrement les modules désactivés.
Pensez aussi aux processus d'arrière-plan. Magento fonctionne avec des tâches cron et souvent avec des consommateurs de files d'attente qui s'exécutent comme processus PHP distincts en ligne de commande. Après la mise à jour de PHP, ils doivent redémarrer tout comme PHP-FPM. Après un changement de version majeure de PHP, faites en outre reconstruire le code généré dans generated/ et les fichiers statiques, et parcourez la boutique dans un environnement de test avant de reprendre l'exploitation en production. La manière de réussir proprement le redémarrage est décrite dans Redémarrer PHP-FPM et tous les workers.
Ce qu'une mise à jour de Magento peut faire et ne peut pas faire
Une version de Magento ou un correctif de sécurité d'Adobe comble des défauts dans le code de la boutique. Il ne corrige pas PHP, ne redémarre pas les processus FPM, ne supprime pas de scripts de la base de données et n'efface pas de comptes admin étrangers. Si du code a déjà été exécuté, une enquête est nécessaire. La manière de reconnaître des portes dérobées est expliquée dans Reconnaître et supprimer les webshells.
Pour les commerçants acceptant le paiement par carte, ceci s'ajoute : consultez les consignes de votre prestataire de paiement pour les incidents de sécurité et concertez-vous avec lui avant de renouveler des clés. Si une notification à l'autorité de protection des données est nécessaire, vous le clarifiez avec votre délégué à la protection des données ou votre avocat.
Comment PHP SOS aide-t-il concrètement ?
- Nous établissons le PHP web et le PHP CLI de votre serveur Magento et faisons confirmer le correctif et le redémarrage.
- Nous sauvegardons les journaux, les fichiers et la base de données de manière traçable, au besoin via notre investigation numérique.
- Nous contrôlons
env.php,pub/, les modules, les tables de configuration, les blocs CMS et les comptes admin. - Nous nettoyons, renouvelons les clés et les accès et documentons la période d'exposition possible pour la protection des données et le prestataire de paiement.
Questions fréquentes
Un correctif de sécurité Magento comble-t-il aussi PHP2Shell ?
Non. Les correctifs Magento corrigent des défauts dans le code de la boutique. PHP2Shell se situe dans l'interpréteur PHP du serveur et n'est comblé que par une mise à jour de PHP ou un backport confirmé avec redémarrage de tous les processus.
Où les attaquants cachent-ils les skimmers de cartes bancaires dans Magento ?
Souvent pas dans des fichiers, mais dans la base de données, par exemple dans les réglages pour des scripts supplémentaires dans l'en-tête de page ou dans les blocs CMS. C'est pourquoi un contrôle de la base de données fait toujours partie des vérifications en cas de soupçon.
Qui corrige PHP pour Adobe Commerce dans le cloud ?
Cela dépend de votre contrat et de votre environnement. Demandez par écrit à Adobe ou à votre exploitant l'état de PHP et le redémarrage. Les extensions propres et le contenu de la base de données restent sous votre responsabilité.
Pourquoi app/etc/env.php est-il si important ?
Le fichier contient l'accès à la base de données, la clé de chiffrement et le chemin vers l'espace d'administration. Qui a pu le lire peut déchiffrer des valeurs chiffrées et trouver l'administration. En cas de soupçon, ces valeurs devraient être renouvelées.