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.
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.
What to check first
-
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.
-
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.
-
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.
-
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
Describe your need in one minute
A few targeted questions so I can reply with an estimate rather than another questionnaire.