| Module | xipblog |
|---|---|
| Nom technique | xipblog |
| Éditeur | xpert-idea |
| Identifiant | CVE-2023-27847 |
| Score CVSS | 9.8 / 10 |
| Type | Injection SQL non authentifiée |
| Versions touchées | <= 2.0.1 |
| Version corrigée | aucune confirmée |
| Publication de l'avis | 23 mars 2023 |
Attention
Le correctif a été publié sans changer le numéro de version : la version seule ne permet pas de savoir si le module est corrigé.
Suis-je concerné ?
Étape 1
Le module est-il présent ?
Par FTP ou dans le gestionnaire de fichiers de votre hébergeur, cherchez le dossier modules/xipblog/. Un module désinstallé mais toujours présent sur le serveur reste exploitable.
Étape 2
Quelle version ?
Dans le back-office (Modules > Gestionnaire de modules), ou dans le fichier config.xml du dossier du module.
Étape 3
Comparer
Versions touchées : <= 2.0.1. Aucune version corrigée confirmée par l'avis.
● Test gratuit · 10 secondes
Votre boutique montre-t-elle des signes d'infection ?
Le scan ne peut pas savoir si ce module est installé chez vous, mais il repère ce que ce type de faille sert à implanter : script de vol de carte, code caché, redirection. Réponse en 10 secondes, gratuit, sans inscription.
Scan passif de votre page d'accueil, comme un visiteur. Sans inscription. Scannez uniquement un site dont vous êtes responsable.
Que faire
Étape 1
Supprimer ou corriger
En l'absence de version corrigée confirmée, supprimer le module du serveur ou faire appliquer un correctif vérifié.
Étape 2
Partir du principe que la boutique a pu être touchée
La faille est exploitée activement : une mise à jour ne retire pas un skimmer déjà installé. Faites vérifier les fichiers du cœur, les modules, la base de données et la page de paiement.
Étape 3
Chercher des traces dans les journaux
Recherchez dans les journaux d'accès des requêtes vers modules/xipblog/ et des requêtes POST inhabituelles, en gardant en tête que les journaux des hébergeurs ne remontent souvent qu'à quelques semaines.
Étape 4
Changer les accès
Mots de passe de l'administration et de la base de données, surtout si la faille permet de lire la base.
Pourquoi c'est urgent
Les failles exploitées activement sont scannées automatiquement par des robots sur des milliers de boutiques. Une boutique vulnérable n'est pas « peut-être » visée : elle le sera.
Sur PrestaShop, l'objectif le plus fréquent est l'installation d'un skimmer qui vole les cartes bancaires de vos clients, avec les obligations qui en découlent (notification à la CNIL, information de la banque).
Source
Avis de sécurité Friends Of Presta : security.friendsofpresta.org/modules/2023/03/23/xipblog.html. Données vérifiées le 24 septembre 2026 ; reportez-vous à l'avis pour les détails techniques.