# My site redirects to an unknown site

> A visitor lands on your store and ends up somewhere else, sometimes only on mobile or only when coming from Google: this behaviour has a precise technical cause, almost always a file or database modified without your knowledge.

- Source canonique : [https://allaux.fr/en/securite/site-redirige-vers-site-inconnu](https://allaux.fr/en/securite/site-redirige-vers-site-inconnu)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Open the .htaccess file at the root, then those in subfolders: a redirect rule added at the top of the file is the most common case. On WordPress, check the siteurl and home fields in the wp_options table next — they can point to a foreign domain. Always test from a mobile device arriving via a search result, never by typing the address.

## The forms this redirect takes

- Systematic redirect the moment the homepage opens, to a site unrelated to your business
- Redirect only when the visitor comes from Google, never when typing the address directly (the attacker targets search traffic)
- Redirect only on mobile, the site behaves normally on desktop
- A payment form flashes briefly before the real one, or an unusual extra input field appears at checkout
- The behaviour disappears once you clear your browser cache, which wrongly suggests a local issue

## Where this redirect technically comes from

An unwanted redirect almost always comes from code injected somewhere in the page's rendering chain: a modified PHP file, an entry added to a configuration table, or a JavaScript loaded from an external domain. The fact that the redirect only triggers under certain conditions (mobile only, or only from a search engine) isn't chance: it's a deliberate technique to delay detection by the merchant, who usually tests the site by typing the address directly on their own computer.

On PrestaShop, this kind of injection generally targets either the CMS core through a flaw in an installed module, or the checkout template directly. One vulnerability of this type is publicly documented: CVE-2022-36408 (also referenced as CVE-2022-31181), disclosed on 22 July 2022, affected the PrestaShop core from 1.6.0.10 up to and including 1.7.8.6, and has been fixed since 1.7.8.7. It could only be exploited by chaining it to an SQL injection present elsewhere on the store: the Wishlist module (blockwishlist) in versions 2.0.0 to 2.1.0 supplied one (CVE-2022-31101, fixed in 2.1.1). Which shows that an up-to-date platform can still be exposed if one of its modules isn't.

More recently, security research firm Sansec published an alert on 20 February 2026 describing an active payment skimmer detected on 16 February 2026 at a large retailer running PrestaShop. The pattern observed: a fake payment form is injected and shown before the real one, and the data entered is sent to an external domain disguised as a traffic-analytics service. Sansec places this incident within a wider wave of attacks targeting PrestaShop, identified in January 2026. The figure of nearly 300,000 active stores comes from PrestaShop itself, not from Sansec; it simply explains why the platform is a valuable target. Comparable campaigns were observed by Sansec on WordPress, Magento and OpenCart. I won't go into the exploitation mechanics here: what a merchant needs to remember is that a payment form that seems to duplicate or flash twice is never a display glitch to ignore.

## Don't test from your own browser

> If the redirect only targets certain visitors (mobile, coming from Google), testing from your usual browser, already recognised as an administrator, may show nothing. Use an online URL scanning tool or a private browsing window while logged out.

## What to check first

1. **Compare core files against a clean version** — A PrestaShop core file modified outside an official update is the clearest sign of an injection. Compare it file by file against an archive of the same version downloaded from the official source.
2. **Check recently installed or updated modules** — A payment module or a secondary module installed for a one-off feature is the most common entry point. Its last official update date gives a first indication of its exposure.
3. **Inspect the checkout form template** — A redirect or an extra form at checkout should always be checked directly in the template code, not just in what's visible in the browser.
4. **Check access logs around the estimated intrusion date** — Unusual requests to admin files or module entry points point towards the flaw that was used.

## Going further

- **Check if my site is compromised** — Free checks to run before paying for a full audit. ([/securite/verifier-si-mon-site-est-compromis](/securite/verifier-si-mon-site-est-compromis))
- **What to do in the first two hours** — The exact order of priorities once the doubt is confirmed. ([/securite/que-faire-dans-les-deux-heures](/securite/que-faire-dans-les-deux-heures))
- **Security service** — Diagnosis, cleanup and closing the flaw on PrestaShop. ([/services/securite](/services/securite))

## FAQ

### Does the redirect affect all my visitors the same way?

No, that's rarely the case. Many injections only target mobile or visitors coming from a search engine, to delay detection by the merchant testing from their own computer.

### Is this linked to a known PrestaShop flaw?

It can be a core flaw, but the most common case is still an installed module that wasn't updated. CVE-2022-36408 illustrates this: it targeted the core from 1.6.0.10 up to and including 1.7.8.6, but needed an SQL injection to be exploitable, the Wishlist module's in versions 2.0.0 to 2.1.0 for instance.

### Should I worry about my customers' card details?

If the redirect touches the payment page or an extra form appears, yes, you should assume data may have been captured and treat that as the priority before any other cleanup.

### Is restoring a backup enough to stop the redirect?

It may stop the visible symptom temporarily, but if the backup dates from after the intrusion, or the entry point isn't identified, the behaviour comes back quickly.

### How do I know if my site has been flagged as dangerous?

A check with an online URL scanning tool, or a check in Google Search Console if you have access, will show whether the domain has been marked as compromised.