En bref : la faille de sécurité PrestaShop qui fait actuellement les gros titres est PHP2Shell et se trouve dans PHP, pas dans la boutique. Une mise à jour de PrestaShop n'aide pas contre elle. Après le correctif PHP et le redémarrage, vous devriez contrôler le dossier override, les modules, le paiement et les comptes employés.
Ce que PHP2Shell signifie pour les commerçants PrestaShop
PrestaShop est une application PHP répandue chez les petits et moyens commerçants, souvent sur hébergement mutualisé ou serveurs virtuels simples. Les failles CVE-2026-109618 et CVE-2026-109619 permettent, selon l'équipe PHP, d'exécuter du code malveillant à distance sans authentification, indépendamment de l'état de la boutique.
Pour une boutique, l'enjeu est important : comptes clients, adresses, commandes, factures et accès aux services de paiement et d'expédition. Avec les boutiques, les attaquants visent souvent le paiement, où ils peuvent lire les saisies de paiement avant qu'elles n'arrivent chez le prestataire de paiement.
S'y ajoute le facteur temps. Selon des articles de presse, une première tentative d'attaque a été observée le 17/10/2026, les correctifs sont parus le 21/10/2026. Une boutique accessible durant cette période peut être concernée, même si tout semble normal aujourd'hui. Il n'existe pour l'instant aucun indicateur de compromission (IoC) confirmé ; les indices ressortent d'un comportement inhabituel, de nouveaux fichiers et de modifications dans la base de données.
Faille de sécurité PrestaShop : vérifier la version de PHP dans le Back Office
Sous Paramètres avancés > Informations, PrestaShop affiche les indications sur le serveur et PHP de l'installation en cours. Les versions corrigées en amont sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Les hébergeurs appliquent parfois les correctifs sous forme de backport, le numéro affiché reste alors identique. Faites-vous confirmer l'état par écrit.
Les versions de PHP prises en charge par votre version de PrestaShop se vérifient dans la configuration requise de la documentation du fabricant sur prestashop.com. Les anciennes boutiques des versions 1.6 et 1.7 tournent souvent sur d'anciens états de PHP ; ce qui figure sous Mesures immédiates sans correctif s'applique alors, jusqu'à ce qu'une mise à niveau soit possible.
Cachettes typiques du code malveillant dans PrestaShop
| Emplacement | Contenu | Point de contrôle |
|---|---|---|
app/config/parameters.php (versions anciennes config/settings.inc.php) |
Accès à la base de données, clé de cookie | Date de modification, renouveler en cas de soupçon |
override/ |
classes et contrôleurs surchargés | chaque fichier doit pouvoir s'expliquer |
modules/ |
Modules de la place de marché et de tiers | modules inconnus, fichiers modifiés |
themes/ |
Modèles et JavaScript, y compris pour le paiement | scripts étrangers |
img/, upload/, download/ |
Images, uploads des clients, produits numériques | aucun fichier PHP |
var/cache/, var/logs/ |
Cache et journaux | sauvegarder les journaux, régénérer le cache |
install/ |
Dossier d'installation | ne doit pas être présent en exploitation |
Le dossier override mérite une attention particulière. Le code qui y est déposé remplace des parties de PrestaShop, par exemple le traitement des commandes ou des paiements, et n'est pas supprimé automatiquement lors des mises à jour.
Contrôles sans danger en ligne de commande et dans la base de données (préfixe de table selon l'installation) :
find override -name "*.php" -newermt "2026-10-17"
find img upload download -type f -name "*.php"
ls -d admin*
SELECT email, firstname, lastname, active FROM ps_employee;
Si des clients signalent des pages de paiement inhabituelles ou une utilisation frauduleuse de leur carte après un achat, déconnectez le paiement du réseau et sauvegardez les journaux à partir du 20/10/2026. Un paiement manipulé peut intercepter des données à chaque achat suivant.
Back Office, comptes employés et modules
Le Back Office se trouve dans un répertoire au nom individuel, attribué à l'installation. Vérifiez sous Paramètres avancés les comptes employés et les profils à la recherche d'accès inconnus ou orphelins, par exemple d'anciennes agences. Limitez si possible le répertoire admin aux réseaux connus.
Les modules de la place de marché et de tiers étendent le paiement, l'expédition, le marketing et les interfaces. Chaque module est du code PHP supplémentaire, et les modules sans maintenance active comptent parmi les portes d'entrée les plus fréquentes des boutiques PrestaShop. Désinstallez et supprimez ce qui n'est pas utilisé, au lieu de simplement le désactiver. Contrôlez aussi les clés de webservice de l'API à la recherche d'entrées inconnues.
Ce qu'une mise à jour de PrestaShop peut faire et ne peut pas faire
Une mise à jour de PrestaShop ou de modules individuels comble des défauts de ce code. Elle ne corrige pas PHP, ne redémarre pas de processus et ne supprime ni surcharges, ni modules étrangers, ni scripts dans le thème, ni nouveaux comptes employés. Si des données personnelles ont été interceptées, une obligation de notification peut en outre exister ; des informations générales sont proposées par Obligation de notification RGPD : 72 heures, l'évaluation au cas par cas relève de votre délégué à la protection des données. Ce que les commerçants devraient observer en plus est résumé dans Sécurité informatique pour les boutiques en ligne.
Pour les boutiques multipays ou à fonction multiboutique, plusieurs domaines tournent souvent sur la même installation. Une découverte concerne alors toutes les boutiques, même si l'anomalie n'a été remarquée que dans l'une d'elles.
Comment PHP SOS aide-t-il concrètement ?
- Nous clarifions avec votre hébergeur l'état de PHP, le backport et le redémarrage.
- Nous sauvegardons les journaux, les fichiers et la base de données et documentons l'état initial.
- Nous contrôlons les surcharges, les modules, le thème, les dossiers d'upload, les comptes employés et les clés de webservice.
- En cas de découvertes, notre suppression de malwares se charge du nettoyage et du renouvellement des accès.
Questions fréquentes
Une mise à jour de PrestaShop comble-t-elle PHP2Shell ?
Non. Les mises à jour de PrestaShop corrigent des défauts du code de la boutique. Les failles PHP2Shell se situent dans l'interpréteur PHP et ne sont comblées que par une mise à jour de PHP ou un backport confirmé avec redémarrage de tous les processus PHP.
Où vois-je la version de PHP dans PrestaShop ?
Dans le Back Office, sous Paramètres avancés > Informations. Vous y trouvez les indications sur le serveur et PHP. Un backport appliqué ne se reconnaît pas au numéro ; c'est votre hébergeur qui le confirme.
Qu'est-ce que le dossier override et pourquoi le contrôler ?
Dans le dossier override, des classes et des contrôleurs de PrestaShop peuvent être surchargés. Le code qui s'y trouve s'exécute à la place de l'original, par exemple au paiement. Les surcharges inconnues sont donc un point de contrôle important en cas de soupçon.
Le répertoire admin doit-il être renommé ?
À l'installation, PrestaShop attribue un nom propre au répertoire admin. Cela rend sa découverte plus difficile, mais ne remplace ni des mots de passe robustes, ni l'authentification à deux facteurs, ni une restriction d'accès.