Attackers have compromised 953 online shops, most using Magento, in a campaign that increasingly conceals its activity from automated security checks. Research by Dutch e-commerce security company Sansec, reported by Infosecurity Magazine on 27 October 2026, describes malicious JavaScript that distinguishes shoppers from scanners before deciding what to deliver.
The findings expose two weaknesses in how retailers establish that a website is safe: an automated inspection may see different content from a customer, and installing security patches may not remove access attackers have already secured. The report does not establish the geographical distribution of affected shops or what the final malicious payload does.
What happened
Sansec traced the campaign back to July 2025 and identified five domains used to serve its loader, the code that retrieves further instructions. The latest domain was registered on 6 October and appeared in content management system blocks on 83 shops. Of those, 60 had previously contained an older loader.
The malicious code sits in Magento’s cms_block database table, placing it within stored website content. When a visitor encounters it, their browser contacts infrastructure controlled by the attackers. The server assesses the request before responding, withholding malicious content when it identifies a security scanner.
Earlier versions used Keitaro, a traffic distribution system, to select between sending a payload, redirecting a visitor or providing nothing. A version Sansec first observed on 7 October contacted the new domain directly and could execute code previously saved in the browser.
That browser-side storage gives the attack a persistence mechanism beyond the live connection to its delivery infrastructure. Once a visitor has received the payload, subsequent page loads can execute the stored code even if the domain has become unavailable or has been blocked.
A further revision on 23 October introduced browser fingerprinting. It checked for indicators of automation and gathered information including hardware characteristics, screen dimensions, time zone and language. Those details informed the server’s decision about what to return.
Sansec observed the practical effect when the scanning service urlscan.io visited an affected shop through an automated browser: no injected content appeared. The researchers have not obtained the final payload. Consequently, the evidence does not yet establish whether the campaign is stealing payment details, redirecting customers to fraud or pursuing another objective.
The background
The campaign also illustrates the difference between closing a software vulnerability and removing an existing compromise. Sansec attributed a March wave, which planted the loader on 471 shops within an hour, to webshells installed through PolyShell, tracked as CVE-2026-48356. Webshells provide a means of remotely controlling a compromised web server.
Among 169 infected Magento 2 installations missing at least one core patch, 102 showed evidence of file uploads through either PolyShell or SessionReaper, CVE-2025-54236. Those findings identify exploitation routes in part of the affected population, rather than a single proven entry point across all 953 shops.
A separate case involved a fully patched shop running Magento 2.4.7-p10. It acquired the latest loader on 23 October, just an hour after a scan had found it clean. Sansec had already identified an unauthorised administrator account and a GSocket backdoor there in September.
For UK and European retailers, that distinction matters when assessing recovery. Updates remain necessary, as our coverage of Chrome and Firefox security releases also highlights, but patch status alone cannot establish that an attacker has been expelled. Sansec warned that deleting this script does not revoke an intruder’s database write access: retained access can allow the malicious content to be inserted again.
What people are saying
Sansec’s advice to merchants extends beyond inspecting website files. According to Infosecurity Magazine, the company recommends searching CMS content for the loader, auditing administrator accounts and investigating backdoors. That puts content management and access controls within the scope of the response, rather than leaving the investigation solely to teams responsible for software updates.
The researchers also recommend replacing database, administrator and integration credentials once the shop has been cleaned. The timing is important: changing secrets while an intruder retains access risks exposing their replacements. Integration credentials deserve particular attention because they support connections between the shop and other systems, broadening the work beyond the accounts used by staff.
Sansec additionally advises merchants to install the latest Magento and Adobe Commerce security updates. Its recommendations therefore describe several distinct recovery tasks, with different evidence needed to establish that each has been completed. A record of deployed updates answers a different question from an account audit or a search for unauthorised remote access.
What happens next
For retailers commissioning an investigation, the immediate operational question is who can examine each part of the environment. Where hosting, storefront maintenance and security monitoring are handled by separate providers, the response may require access and evidence from all three. Responsibility for checking stored content should be explicit, rather than assumed to sit within a routine infrastructure inspection.
The findings also raise a question for organisations procuring website monitoring: what does a clean result actually cover? An assessment should distinguish inspection of the underlying store from observation of a particular browser session. For risk leaders, that distinction affects how much confidence can reasonably be attached to a supplier’s assurance that a site is safe.
Any subsequent customer-impact assessment will need evidence beyond the presence of the loader. Investigators would need to establish which visitors received additional code and what that code accessed or transmitted. The number of compromised shops is not a measure of the number of affected customers, and should not be presented as one.
For UK and European organisations, those findings would inform any assessment of personal-data exposure and applicable notification duties. A technical compromise warrants investigation, but a public claim that customer information was stolen requires supporting evidence. Incident communications should keep confirmed observations separate from scenarios still being examined.
Recovery checks will also need to cover the credentials replaced during remediation. Retailers should establish which legitimate services rely on them and verify those connections afterwards, so that closing unauthorised access does not leave essential integrations silently failing.
