Module PrestaShop gmfeed (MyPresta) : faille critique CVE-2026-85520, que faire ?

TL;DRUne faille critique touche le module PrestaShop Google Merchant Center Feed (gmfeed) de MyPresta : sans aucun mot de passe, un attaquant peut écrire un fichier PHP sur le serveur et prendre le contrôle de la boutique. Voici comment savoir si vous êtes concerné, comment corriger, et comment vérifier que personne n'est déjà entré.

📌 Ce qu'il faut savoir en une minute#

Le 29 septembre 2026, le CERT Polska a publié l'avis CVE-2026-85520. Il concerne le module PrestaShop Google Merchant Center Feed (dossier gmfeed), édité par MyPresta, qui sert à générer le flux de produits envoyé à Google Merchant Center.

La faille est une écriture de fichier arbitraire sans authentification. N'importe quel visiteur, sans compte ni mot de passe, peut demander au module d'écrire un fichier sur le serveur en choisissant son nom, son emplacement, son extension et son contenu. S'il dépose un fichier .php dans un dossier accessible depuis le web, il n'a plus qu'à l'appeler pour exécuter son propre code : c'est une exécution de code à distance (RCE), donc la prise de contrôle de la boutique.

🔒 Comment la faille fonctionne#

Le module propose une fonction « Save to file » : au lieu de recalculer le flux à chaque visite de Google, il l'enregistre dans un fichier, en général par une tâche planifiée (cron) qui appelle une adresse du type modules/gmfeed/feed.php.

D'après l'avis du CERT Polska, ce point d'entrée ne vérifiait ni l'identité de l'appelant ni les paramètres reçus. Or ces paramètres pilotent le nom du fichier de sortie, son chemin, son extension et son contenu. Deux protections manquaient donc en même temps :

• l'autorisation : rien ne distinguait la tâche planifiée légitime d'un inconnu ;
• la validation des entrées : rien n'interdisait une extension .php ni un chemin sortant du dossier prévu.

Nous ne détaillons pas la requête d'attaque. Retenez qu'elle tient en un seul appel HTTP et qu'elle ne demande aucune compétence particulière une fois l'outil en main.

📌 Pourquoi il faut agir maintenant#

Une faille sans authentification, exploitable en une requête, se prête au balayage automatique : un script parcourt des milliers de boutiques et teste si feed.php répond. Au moment de la publication de l'avis, aucune exploitation massive n'était documentée. Depuis, nous avons constaté qu'au moins un code d'exploitation public circule, avec un mode de test en masse. Nous ne le relayons pas, mais cela signifie que le délai entre l'annonce et les premières attaques est déjà écoulé.

Les conséquences d'une compromission sont celles d'un accès complet au serveur web : lecture de la base (clients, commandes), modification des pages de paiement, envoi de spam, installation d'une porte dérobée qui survit à la mise à jour du module.

🎯 Votre boutique est-elle concernée ?#

1. Le module est-il présent ? Dans le back-office, ouvrez le gestionnaire de modules et cherchez « Google Merchant Center Feed ». Vérifiez aussi sur le serveur : un dossier modules/gmfeed/ peut subsister alors que le module est désactivé.
2. Quelle version ? Elle figure dans le gestionnaire de modules et dans le fichier principal du module. En dessous de 2.3.10, considérez la boutique comme exposée.
3. Un module désactivé protège-t-il ? Non, pas à lui seul. Tant que le fichier feed.php est sur le serveur, il peut être appelé directement. C'est la raison pour laquelle l'éditeur demande de supprimer les fichiers.

📌 Le plan de correction, dans l'ordre#

1. Sauvegardez les fichiers et la base avant toute manipulation, et conservez les journaux d'accès du serveur : ils serviront à l'audit.
2. Désinstallez complètement le module et supprimez le dossier modules/gmfeed/. N'installez pas la nouvelle archive par-dessus l'ancienne : des fichiers obsolètes, ou déposés par un attaquant, resteraient en place.
3. Installez la version 2.4.1 (au minimum 2.3.10) récupérée depuis votre espace client MyPresta, et pas depuis une archive trouvée ailleurs.
4. Régénérez toutes les adresses « Save to file » et mettez à jour vos tâches cron. La version corrigée ajoute une clé propre à chaque boutique dans ces adresses : les anciennes ne fonctionneront plus, et c'est voulu.
5. Mettez à jour l'adresse du flux dans Google Merchant Center si elle a changé, puis vérifiez que le flux est bien récupéré.

Si vous ne pouvez pas mettre à jour tout de suite, coupez l'accès au fichier en attendant : bloquez modules/gmfeed/feed.php au niveau du serveur ou du pare-feu applicatif, et désactivez la génération du flux par URL. C'est une mesure d'attente, pas un correctif.

📌 Vérifier que la boutique n'a pas déjà été compromise#

Mettre à jour ferme la porte, mais ne dit pas si quelqu'un est déjà entré. Trois vérifications sont à faire.

📌 1. Chercher des fichiers PHP inattendus#

Listez les fichiers PHP récents du module et des dossiers où PrestaShop écrit, et comparez avec l'archive officielle :

find modules/gmfeed -type f -name "*.php" -mtime -90 -ls
find img upload download var -type f -name "*.php" -ls

Un fichier PHP dans img/, upload/ ou download/ n'a en principe rien à y faire (hors fichiers index.php de protection, très courts). Ouvrez tout fichier au nom aléatoire, récent ou au contenu illisible.

📌 2. Relire les journaux d'accès#

Recherchez les appels au point d'entrée du module et regardez d'où ils viennent :

grep "gmfeed/feed.php" /chemin/vers/access.log

Les appels légitimes viennent de votre tâche cron ou de Google, à heures régulières. Des appels venus d'adresses inconnues, avec des paramètres inhabituels, sont un signal d'alerte.

📌 3. En cas de doute, traiter comme une compromission#

Si vous trouvez un fichier suspect : isolez-le sans le supprimer (il sert de preuve), changez les mots de passe du back-office, de la base de données et des accès FTP ou SSH, renouvelez les clés d'API des modules de paiement, et recherchez d'autres portes dérobées sur l'ensemble du site. Si des données de clients ont pu être consultées, la question d'une notification à la CNIL se pose : faites-vous accompagner.

📌 Comment auditer régulièrement vos modules tiers#

Cette faille n'a rien d'exotique : un fichier appelé directement, sans contrôle, qui écrit sur le disque. Elle aurait pu toucher n'importe quel module. Quelques habitudes réduisent nettement le risque.

• Tenir un inventaire. La liste des modules installés, leur version, leur éditeur et la date de dernière mise à jour. On ne corrige pas ce qu'on ne sait pas avoir.
• Supprimer ce qui ne sert plus. Un module désactivé dont les fichiers restent sur le serveur reste une surface d'attaque.
• Suivre les avis de sécurité. Les publications des CERT et les bulletins des éditeurs de vos modules, au moins une fois par semaine.
• Interdire l'exécution de PHP là où on écrit des fichiers. Les dossiers d'images, d'envois et de téléchargements ne doivent pas pouvoir exécuter un script, même si un attaquant réussit à en déposer un.
• Surveiller les fichiers. Une comparaison régulière des fichiers du site avec un état de référence signale tout fichier PHP apparu sans déploiement.
• Tester les sauvegardes. Une sauvegarde qui n'a jamais été restaurée n'est qu'une hypothèse.

C'est le travail de fond d'une maintenance : si vous n'avez pas le temps de le faire, notre agence PrestaShop peut reprendre la maintenance de votre boutique. Sur le même sujet, voir aussi notre analyse de la faille WordPress CVE-2026-87902, qui mène elle aussi à une exécution de code à distance.

📌 Une précision sur les numéros de version#

Les sources ne donnent pas exactement le même seuil. L'avis du CERT Polska indique les versions 1.9.1 à 2.3.8 comme vulnérables et la 2.3.9 comme corrigée. Les consignes relayées depuis l'éditeur demandent de considérer toute version inférieure à 2.3.10 comme non sûre et recommandent la 2.4.1. Dans le doute, nous retenons la consigne la plus stricte : passez directement en 2.4.1.

❓ Questions fréquentes#

📌 Qu'est-ce que la CVE-2026-85520 ?#

C'est une faille du module PrestaShop Google Merchant Center Feed (gmfeed) de MyPresta. Le fichier feed.php permettait à un visiteur non authentifié d'écrire un fichier de son choix sur le serveur, ce qui peut conduire à l'exécution de code à distance.

📌 Quelles versions du module gmfeed sont vulnérables ?#

L'avis du CERT Polska cite les versions 1.9.1 à 2.3.8. L'éditeur demande de considérer toute version inférieure à 2.3.10 comme non sûre et recommande la 2.4.1.

📌 Désactiver le module suffit-il ?#

Non. Tant que les fichiers du module sont sur le serveur, feed.php peut être appelé directement. Il faut désinstaller le module et supprimer le dossier modules/gmfeed/ avant d'installer la version corrigée.

📌 Pourquoi faut-il régénérer les adresses « Save to file » ?#

La version corrigée ajoute une clé propre à chaque boutique dans ces adresses. Les anciennes adresses et les anciennes tâches cron ne fonctionnent plus et doivent être recréées depuis le back-office.

📌 Comment savoir si ma boutique a été piratée ?#

Cherchez des fichiers PHP récents ou inconnus dans modules/gmfeed/ et dans les dossiers d'images et d'envois, et relisez les journaux d'accès à la recherche d'appels à gmfeed/feed.php venant d'adresses inconnues.

🛒 Le cœur de PrestaShop est-il touché ?#

Non. La faille se trouve dans un module tiers édité par MyPresta, pas dans PrestaShop lui-même. Une boutique sans ce module n'est pas concernée par cette CVE.

Article rédigé le 05/10/2026 par l'équipe Websource à partir des sources citées ci-dessus, puis relu avant publication. Une information vous semble inexacte ou datée ? Signalez-le nous, nous corrigeons.