# Faille de sécurité Shopware 6 (PHP2Shell) : comment sécuriser votre boutique > Shopware 6 et PHP2Shell : pourquoi la mise à jour de la boutique ne suffit pas, où se cache le code malveillant (.env, plugins, public) et que contrôler. Source : https://phpsos.de/fr/plattformen/shopware-6/ État : 25/10/2026 Fournisseur : PHP SOS, Assistance d'urgence PHP et sécurité des serveurs. Aide immédiate par WhatsApp : https://wa.me/491736494914?text=Bonjour%20PHP%20SOS%2C%20nous%20avons%20besoin%20d%27aide%20avec%20notre%20serveur%20PHP.%20Entreprise%20%3A%20%E2%80%A6%20Site%20web%20%3A%20%E2%80%A6 **En bref :** la faille de sécurité Shopware 6 que de nombreux commerçants recherchent actuellement est en réalité une faille de PHP. Les mises à jour de Shopware ne la comblent pas. Il vous faut un PHP corrigé avec redémarrage de tous les processus, puis vous devriez contrôler `.env`, `custom/plugins`, le dossier `public` et les intégrations API. ## Ce que PHP2Shell signifie pour Shopware 6 Shopware 6 repose sur le framework PHP Symfony et fonctionne le plus souvent avec PHP-FPM derrière Nginx ou Apache. Les failles CVE-2026-109618 et CVE-2026-109619 concernent précisément ce mode d'exploitation. Selon l'équipe PHP, elles permettent d'exécuter du code malveillant à distance, sans connexion à la boutique. Un attaquant qui exécute du code sur le serveur atteint tout ce à quoi la boutique accède elle-même : données clients, commandes, documents de facturation, identifiants de la gestion des stocks et des prestataires de paiement. Nous expliquons le contexte technique sous [Qu'est-ce que PHP2Shell ?](https://phpsos.de/fr/php2shell/was-ist-php2shell/). ## Vérifier la faille Shopware 6 : quel PHP fonctionne réellement ? Shopware 6 est beaucoup administré en ligne de commande, par exemple avec `bin/console`. Une erreur est alors facile : `php -v` indique la version du PHP en ligne de commande, pas nécessairement celle de PHP-FPM, qui traite les requêtes de la boutique. Sur de nombreux serveurs, plusieurs versions de PHP sont installées en parallèle. Sont fiables l'indication du panneau d'hébergement pour le domaine concerné et la confirmation de l'hébergeur sur l'état des paquets. Les versions corrigées en amont sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35 ; les backports peuvent porter des numéros plus anciens. Les versions de PHP prises en charge par votre version de Shopware se vérifient dans la configuration requise de la documentation sur shopware.com. Comment vérifier vous-même, vous le trouverez sous [Vérifier correctement la version de PHP et l'état du correctif](https://phpsos.de/fr/php2shell/php-version-pruefen/). Un point est souvent négligé avec Shopware 6 : de nombreuses boutiques traitent la file d'attente des messages et les tâches planifiées via des processus d'arrière-plan en fonctionnement permanent, par exemple `bin/console messenger:consume` sous un gestionnaire de processus. Ces processus chargent PHP une seule fois au démarrage. Après la mise à jour, il faut donc redémarrer non seulement PHP-FPM, mais aussi ces workers. Sinon, une partie de la boutique continue de fonctionner avec l'ancien PHP vulnérable en mémoire. ## Dossiers et fichiers à connaître | Emplacement | Contenu | Pourquoi c'est pertinent | |---|---|---| | `.env`, `.env.local` | Accès à la base de données, `APP_SECRET`, autres clés | À renouveler en cas de soupçon | | `public/` | Racine web avec `index.php`, médias, fichiers de thème | Des fichiers PHP supplémentaires sont suspects | | `public/theme/` | Fichiers JavaScript et CSS compilés de la vitrine | Endroit pour les skimmers introduits | | `custom/plugins/`, `custom/apps/` | Extensions | Code de plugin modifié | | `files/` | Fichiers privés comme les factures et les bons de livraison | Données personnelles | | `var/log/` | Journaux de la boutique | Sauvegarder les traces | Premiers contrôles sans danger : ```bash # Afficher les plugins installés avec version et statut bin/console plugin:list # Lister les fichiers PHP du dossier public find public -type f -name "*.php" # Afficher les failles connues dans les dépendances Composer composer audit ``` Dans le dossier `public/`, il ne devrait y avoir que peu de fichiers PHP, tous connus. Tout ce qui est inconnu doit être sauvegardé et examiné, pas supprimé immédiatement. > **Astuce:** > Dans l'administration, sous Réglages > Système, contrôlez les sections « Utilisateurs et droits » et « Intégrations ». Des utilisateurs ou des intégrations API inconnus sont une porte dérobée que n'importe quelle analyse de fichiers manque. ## Accès administrateur, plugins et apps comme risque L'administration se trouve par défaut sous `/admin`. Protégez-la avec des comptes personnels, une authentification forte et, si possible, une restriction d'accès aux réseaux connus. Les intégrations pour la gestion des stocks, les places de marché ou les transporteurs ne devraient avoir que les droits dont elles ont réellement besoin. Les plugins du store et les développements spécifiques apportent leur propre code PHP, les apps y ajoutent des webhooks vers des serveurs externes. Plus il y a d'extensions, plus la surface d'attaque est grande et plus chaque mise à niveau de PHP est lourde. Supprimez entièrement les plugins qui ne sont plus utilisés. ## Ce qu'une mise à jour de Shopware peut faire et ne peut pas faire Une mise à jour de Shopware ou d'un plugin comble des défauts connus dans ce code. Elle ne peut pas : - corriger PHP sur le serveur, - redémarrer d'anciens processus PHP-FPM, - supprimer de façon sûre des fichiers étrangers dans `public/` ou des fichiers de thème manipulés, - supprimer des utilisateurs ou des intégrations étrangers, - prouver que rien ne s'est produit avant le correctif. Après une mise à jour de PHP vers une nouvelle version majeure, vous devriez régénérer le cache et le thème et tester la boutique dans un environnement de test. Notre [service de correctifs PHP](https://phpsos.de/fr/leistungen/php-patch-service/) se charge, sur demande, du changement de PHP avec justificatif. Chez les grands commerçants, Shopware 6 fonctionne souvent sur plusieurs serveurs d'application. Chaque serveur doit alors être corrigé et redémarré, y compris ceux qui n'exécutent que des tâches d'arrière-plan. Si un prestataire exploite la boutique comme plateforme gérée, il devrait vous confirmer l'état de tous les nœuds. ## Comment PHP SOS aide-t-il concrètement ? - Nous établissons quel PHP votre boutique utilise réellement via FPM et clarifions le correctif et le redémarrage avec l'hébergeur ou l'agence. - Nous sauvegardons les journaux à partir du 20/10/2026, la base de données et les fichiers. - Nous contrôlons `public/`, les fichiers de thème compilés, les plugins, les utilisateurs et les intégrations à la recherche d'anomalies. - En cas de découverte, nous nettoyons la boutique avec votre agence et renouvelons les clés et les accès de manière ordonnée. ## Questions fréquentes **Shopware 6 lui-même est-il concerné par PHP2Shell ?** Les failles se trouvent dans PHP, pas dans le code de Shopware. Toute boutique Shopware 6 sur un PHP non corrigé est donc potentiellement vulnérable, quelle que soit la version de Shopware. Une mise à jour de Shopware n'y change rien. **Quel fichier de Shopware 6 est particulièrement critique après une attaque ?** Le fichier .env ou .env.local contenant l'accès à la base de données et APP_SECRET. Qui a pu le lire connaît vos identifiants. En cas de soupçon, ces valeurs devraient être renouvelées, en concertation avec votre agence. **Que sont les intégrations dans Shopware 6 et pourquoi les contrôler ?** Les intégrations sont des accès API pour des systèmes externes comme la gestion des stocks ou les places de marché. Une intégration étrangère avec des droits d'administrateur permet un accès complet à la boutique via l'API, sans qu'aucun fichier ne se trouve sur le serveur. ## Sources - [php.net : avis de sécurité](https://www.php.net/) - [Shopware](https://www.shopware.com/) - [Versions de PHP prises en charge](https://www.php.net/supported-versions.php) - [OWASP Top 10](https://owasp.org/www-project-top-ten/)