Disponible pour missions & renforts d’agence · Réponse rapide, par la personne qui intervient

WhatsApp contact@allaux.fr
FR EN TR
allaux.
Urgence Parler de mon projet

Mon site redirige vers un site inconnu

Un visiteur arrive sur votre boutique et se retrouve ailleurs, parfois seulement sur mobile ou seulement depuis Google : ce comportement a une cause technique précise, presque toujours un fichier ou une base de données modifiés sans votre accord.

Décrire mon problème Discuter sur WhatsApp

Les formes que prend cette redirection

  • Redirection systématique dès l’ouverture de la page d’accueil, vers un site sans rapport avec votre activité
  • Redirection uniquement quand le visiteur vient de Google, jamais en tapant l’adresse directement (le pirate cible le trafic de recherche)
  • Redirection uniquement sur mobile, le site reste normal sur ordinateur
  • Un formulaire de paiement apparaît brièvement avant le vrai formulaire, ou un second champ de saisie inhabituel s’affiche au moment de payer
  • Le comportement disparaît quand vous videz le cache de votre navigateur, ce qui fait croire à tort à un problème local

D’où vient techniquement cette redirection

Une redirection non voulue vient presque toujours d’un code injecté quelque part dans la chaîne d’affichage de la page : un fichier PHP modifié, une entrée ajoutée dans une table de configuration, ou un script JavaScript chargé depuis un domaine externe. Le fait que la redirection ne se déclenche que dans certaines conditions (mobile seulement, ou uniquement depuis un moteur de recherche) n’est pas un hasard : c’est une technique volontaire pour retarder la détection par le marchand, qui teste généralement son site en tapant l’adresse directement depuis son ordinateur.

Sur PrestaShop, ce type d’injection cible en général soit le cœur du CMS via une faille dans un module installé, soit directement le gabarit d’affichage du paiement. Une vulnérabilité de ce type a été documentée publiquement : la faille CVE-2022-36408 (référencée aussi sous CVE-2022-31181), divulguée le 22 juillet 2022, touchait le cœur PrestaShop des versions 1.6.0.10 à 1.7.8.6 incluses, et est corrigée depuis la 1.7.8.7. Elle ne s’exploitait qu’en la chaînant à une injection SQL présente ailleurs sur la boutique : le module Wishlist (blockwishlist) en versions 2.0.0 à 2.1.0 en fournissait une (CVE-2022-31101, corrigée en 2.1.1). Ce qui montre qu’une plateforme à jour peut rester exposée si l’un de ses modules ne l’est pas.

Plus récemment, la société de recherche en sécurité Sansec a publié le 20 février 2026 une alerte décrivant un skimmer de paiement actif détecté le 16 février 2026 chez un grand distributeur utilisant PrestaShop. Le principe observé : un faux formulaire de paiement injecté s’affiche avant le vrai, et les données saisies sont transmises vers un domaine externe déguisé en service d’analyse de trafic. Sansec situe cet incident dans une vague plus large d’attaques visant PrestaShop, identifiée en janvier 2026. Le chiffre de près de 300 000 boutiques actives, lui, vient de PrestaShop et non de Sansec ; il explique simplement pourquoi la plateforme constitue une cible de valeur. Des campagnes comparables ont été observées par Sansec sur WordPress, Magento et OpenCart. Je ne détaille pas ici la mécanique d’exploitation : le point à retenir pour un marchand est qu’un formulaire de paiement qui semble se dédoubler ou apparaître deux fois n’est jamais un bug d’affichage à ignorer.

Ce qu’il faut contrôler en priorité

  1. Comparer les fichiers du cœur à une version saine

    Un fichier du core PrestaShop modifié en dehors d’une mise à jour officielle est le signe le plus direct d’une injection. La comparaison se fait fichier par fichier avec une archive de la même version téléchargée depuis la source officielle.

  2. Vérifier les modules récemment installés ou mis à jour

    Un module de paiement ou un module secondaire installé pour une fonctionnalité ponctuelle est le point d’entrée le plus courant. Sa date de dernière mise à jour officielle donne une première indication de son exposition.

  3. Inspecter le gabarit du formulaire de paiement

    Une redirection ou un second formulaire au moment du paiement doit toujours être vérifié directement dans le code du template, pas seulement dans l’affichage visible au navigateur.

  4. Consulter les logs d’accès autour de la date estimée de l’intrusion

    Les requêtes inhabituelles vers des fichiers d’administration ou des points d’entrée de modules donnent une piste sur la faille utilisée.

Pour aller plus loin

Décrivez votre besoin en 1 minute

Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.

Qu’avez-vous constaté ?
Quelle plateforme ?
Depuis quand le problème est-il constaté ? (facultatif)

Plus l’infection est ancienne, plus elle a pu se propager dans les fichiers et la base de données.

Disposez-vous d’une sauvegarde saine ?

Une sauvegarde antérieure à l’infection change complètement la méthode de remise en état.

Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Questions fréquentes

La redirection touche-t-elle tous mes visiteurs de la même façon ?
Non, c’est rarement le cas. Beaucoup d’injections ciblent uniquement le mobile ou uniquement les visiteurs venus d’un moteur de recherche, pour retarder la détection par le marchand qui teste depuis son propre poste.
Est-ce lié à une faille connue de PrestaShop ?
Cela peut être une faille du cœur, mais le cas le plus fréquent reste un module installé qui n’a pas été mis à jour. La CVE-2022-36408 illustre ce mécanisme : elle visait le cœur en versions 1.6.0.10 à 1.7.8.6 incluses, mais avait besoin d’une injection SQL pour être exploitée, celle du module Wishlist en versions 2.0.0 à 2.1.0 par exemple.
Dois-je m’inquiéter pour les données bancaires de mes clients ?
Si la redirection touche la page de paiement ou fait apparaître un formulaire supplémentaire, oui, il faut considérer que des données ont pu être capturées et agir en priorité sur ce point avant tout autre nettoyage.
Restaurer une sauvegarde suffit-il pour arrêter la redirection ?
Cela peut arrêter le symptôme visible temporairement, mais si la sauvegarde date d’après l’intrusion ou si la faille d’entrée n’est pas identifiée, le comportement revient rapidement.
Comment savoir si mon site a été signalé comme dangereux ?
Un test avec un outil d’analyse d’URL en ligne, ou une vérification dans Google Search Console si vous y avez accès, indique si le domaine a été marqué comme compromis.

Pages liées