En bref : lorsque le site redirige vers des pages étrangères, la cause se trouve dans l'une de six couches : DNS, CDN ou proxy, configuration du serveur web, code PHP, base de données ou scripts intégrés. Comme beaucoup de redirections ne s'activent que sous conditions, testez de manière ciblée avec différents identifiants et pages d'origine. Protégez d'abord les visiteurs, sécurisez les traces, puis fermez la porte d'entrée après la suppression.
Quand des clients atterrissent sur des sites de jeux-concours
Le signalement vient le plus souvent de l'extérieur. Un client écrit qu'en ouvrant votre site, il s'est retrouvé sur un jeu-concours ou une boutique douteuse. Vous vérifiez sur votre propre ordinateur, et tout semble normal. Ce n'est pas une contradiction, mais voulu : les redirections après un piratage sont conçues pour que les exploitants les remarquent le plus tard possible.
Pour votre entreprise, c'est délicat. Les visiteurs perdent confiance, les moteurs de recherche et les navigateurs peuvent afficher des avertissements, et sur les pages de destination, des escroqueries ou des logiciels malveillants attendent parfois. Une redirection est en outre presque jamais la seule chose qu'un attaquant laisse derrière lui.
Après PHP2Shell, les failles CVE-2026-109618 et CVE-2026-109619 permettant l'exécution de code sans authentification, les redirections font partie des conséquences visibles que les exploitants devraient prendre au sérieux. Elles ne constituent pas un indice spécifique à PHP2Shell, car il n'existe pas d'indicateurs de compromission confirmés. Mais elles montrent que quelqu'un a pu modifier des contenus de votre site.
Souvent, les redirections ne viennent pas seules. Qui redirige les visiteurs crée fréquemment aussi des pages de spam pour les moteurs de recherche, afin de capter encore plus de trafic. Si Google affiche déjà un avertissement de site piraté, le guide Supprimer l'avertissement de Google décrit la marche à suivre pour la vérification. Les pages étrangères dans l'index de recherche sont traitées dans l'article Spam SEO et pages étrangères dans l'index Google.
Pourquoi le site ne redirige que parfois
Les redirections conditionnelles exploitent des caractéristiques de la requête. Voici les plus fréquentes :
- Origine : seul celui qui arrive depuis un résultat de recherche est redirigé. Les accès directs affichent la page normale.
- Appareil : seuls les appareils mobiles ou certains navigateurs sont concernés.
- Répétition : la redirection s'active une fois par visiteur, puis pose un cookie et se tait.
- Connexion : celui qui est connecté au CMS ne voit jamais rien.
- Moment ou hasard : la redirection ne s'active que pour une partie des accès.
Ne testez donc pas seulement depuis votre poste de travail. Une requête en lecture seule montre comment le serveur répond à différents accès :
# Accès normal : code d'état et destination d'une éventuelle redirection
curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' https://www.ihre-domain.de/
# Accès comme depuis un appareil mobile venant d'une recherche
curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' \
-A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X) AppleWebKit/605.1.15 Mobile/15E148" \
-e "https://www.google.com/" https://www.ihre-domain.de/
Si une destination étrangère n'apparaît qu'avec la deuxième requête, la redirection se trouve sur le serveur. Si les deux restent normales, elle peut se produire dans le navigateur via JavaScript. Dans ce cas, un coup d'œil au code source de la page livrée ou à la vue réseau des outils de développement du navigateur aide, de préférence dans une fenêtre privée.
Le site redirige : vérifier les six couches
Procédez de l'extérieur vers l'intérieur. Vous évitez ainsi de chercher des heures dans le code alors que la cause se trouve dans une entrée DNS :
| Couche | Cause typique | Vérification |
|---|---|---|
| Domaine et DNS | enregistrement A ou serveur de noms modifié | comparer les entrées DNS à la valeur attendue connue, vérifier l'accès au bureau d'enregistrement |
| CDN ou proxy | règle de redirection ou de page étrangère | passer en revue les règles dans l'espace client du fournisseur |
| Serveur web | règles dans .htaccess ou dans la configuration du serveur |
rechercher les règles Rewrite et Redirect avec conditions |
| Code PHP | code supplémentaire dans les fichiers d'entrée, les modèles ou les extensions | comparer les fichiers du noyau avec l'original |
| Base de données | paramètres d'adresse modifiés, scripts dans les contenus ou les options | rechercher de façon ciblée des adresses et scripts étrangers |
| Scripts externes | intégration tierce compromise | lister et évaluer les sources de scripts intégrées |
Les couches extérieures sont volontiers sautées, parce qu'elles ne se trouvent pas sur votre propre serveur. C'est précisément pourquoi elles sont dangereuses : qui a pris le contrôle du compte chez le bureau d'enregistrement ou chez le fournisseur de CDN n'a pas besoin d'accéder au serveur. Vérifiez-y, outre les règles, qui a accès et si l'authentification à deux facteurs est active.
Pour la couche du serveur web, des recherches en lecture seule de règles réagissant à l'origine ou à l'appareil conviennent :
# Règles de redirection avec conditions dans tous les fichiers .htaccess
grep -rn --include='.htaccess' -iE 'Rewrite(Cond|Rule)|Redirect' /var/www/ihre-website
# Redirections dans la configuration du serveur (Apache et Nginx)
grep -rn -iE 'Rewrite|Redirect|return 30[12]' /etc/apache2/ /etc/nginx/ 2>/dev/null
Pour la couche PHP, Comparer les fichiers du noyau du CMS avec l'original décrit la démarche. Pour la base de données, l'article Vérifier la base de données à la recherche de code injecté vaut le détour.
Quand la cause se trouve en dehors du serveur
Toute redirection ne signifie pas un serveur compromis. Les scripts de fournisseurs tiers intégrés, par exemple pour le chat, les statistiques ou la publicité, s'exécutent directement dans le navigateur des visiteurs. Si un tel fournisseur est compromis ou si un domaine expire alors que votre site y charge encore un script, une redirection peut en résulter sans qu'aucun fichier ait été modifié sur votre serveur.
Une Content Security Policy limite les sources depuis lesquelles le navigateur peut charger des scripts et rend de tels cas visibles. Des indications se trouvent dans En-têtes de sécurité pour les sites web. Très rarement, la cause se trouve chez le visiteur lui-même : un logiciel publicitaire ou malveillant sur son ordinateur le redirige alors aussi sur d'autres sites.
Le bon ordre après la découverte
- Protéger les visiteurs : mettre le site en mode maintenance ou bloquer les zones concernées.
- Sécuriser les traces : copier avec horodatage les règles, fichiers et contenus de base de données suspects avant de les supprimer.
- Supprimer : éliminer la redirection et remplacer les fichiers du noyau à partir d'une source saine.
- Fermer la porte d'entrée : amener PHP à une version corrigée, mettre à jour le CMS et les extensions, redémarrer tous les workers, renouveler les accès.
- Retester : vérifier à nouveau avec toutes les variantes de la deuxième section et surveiller la Search Console.
Une règle de redirection supprimée n'est pas la preuve d'un site sain. Si la règle revient après quelques jours, une porte dérobée qui la réécrit se cache encore quelque part.
Comment PHP SOS aide-t-il concrètement ?
- Nous reproduisons la redirection avec différents identifiants et pages d'origine et délimitons la couche concernée.
- Nous sécurisons les traces et supprimons redirections, code malveillant et portes dérobées dans les fichiers, la configuration et la base de données.
- En cas d'infection aiguë, notre assistance d'urgence pour sites piratés assure le confinement jusqu'à ce que l'incident soit clos et documenté.
- Nous examinons les scripts de fournisseurs tiers intégrés et recommandons une Content Security Policy adaptée.
Questions fréquentes
Pourquoi ne vois-je pas moi-même la redirection ?
De nombreuses redirections ne s'activent que sous certaines conditions : pour les visiteurs venant de la recherche Google, uniquement sur mobile, seulement à la première visite ou pas pour les administrateurs connectés. Testez donc avec différents appareils, sans être connecté et via un lien de résultat de recherche.
Une redirection peut-elle apparaître sans piratage ?
Oui. Un plugin périmé, un script externe compromis, de fausses entrées DNS ou un logiciel malveillant sur l'ordinateur du visiteur peuvent produire des effets similaires. Si la cause se trouve sur votre propre ordinateur, la redirection se produit généralement aussi sur d'autres sites.
Où les attaquants cachent-ils le plus souvent les redirections ?
Typiquement dans des règles de .htaccess ou de la configuration du serveur, du code supplémentaire dans les fichiers d'entrée de l'application, des paramètres d'adresse modifiés dans la base de données et des fragments JavaScript injectés dans les contenus ou les modèles.
Que dois-je faire immédiatement si mon site redirige ?
Protéger les visiteurs, par exemple avec un mode maintenance, et sécuriser les traces avant de supprimer quoi que ce soit. Ensuite, chercher la cause couche par couche et fermer la porte d'entrée. Une règle supprimée sans que la faille soit fermée revient le plus souvent.