# 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.

- Source canonique : [https://allaux.fr/securite/site-redirige-vers-site-inconnu](https://allaux.fr/securite/site-redirige-vers-site-inconnu)
- Langue : FR
- Dernière mise à jour : 2026-08-03

## Réponse directe

> Ouvrez le fichier .htaccess à la racine, puis ceux des sous-dossiers : une règle de redirection ajoutée en tête de fichier est le cas le plus fréquent. Côté WordPress, vérifiez ensuite les champs siteurl et home de la table wp_options, qui peuvent pointer vers un domaine étranger. Testez toujours depuis un appareil mobile en arrivant par un résultat de recherche, jamais en tapant l’adresse.

## 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.

## Ne testez pas depuis votre propre navigateur

> Si la redirection ne cible que certains visiteurs (mobile, provenance Google), tester depuis votre navigateur habituel, déjà identifié comme administrateur, peut ne rien montrer. Utilisez un outil d’analyse d’URL en ligne ou un navigateur en mode privé sans être connecté.

## 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

- **Vérifier si mon site est compromis** — Les vérifications gratuites à faire avant de payer un audit complet. ([/securite/verifier-si-mon-site-est-compromis](/securite/verifier-si-mon-site-est-compromis))
- **Que faire dans les deux heures** — L’ordre exact des priorités une fois le doute confirmé. ([/securite/que-faire-dans-les-deux-heures](/securite/que-faire-dans-les-deux-heures))
- **Service sécurité** — Diagnostic, nettoyage et fermeture de la faille sur PrestaShop. ([/services/securite](/services/securite))

## FAQ

### 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.