Skip to main content
Emerging ThreatsMalware & Ransomware

Magento Sites Compromised by Advanced Scanner-Evading Malware

Blurred computer workstation in a dimly lit online retail store's back office with stacks of boxes and shelves in the…

Attackers have infected 953 online stores — mostly running Magento — with a JavaScript loader that now distinguishes real shoppers from automated scanners, according to research by Dutch e‑commerce security firm Sansec.

Scanner‑evading loader behavior

Sansec reports the campaign has been active since July 2025 and has cycled through five loader domains. The most recent domain, registered on October 6, was discovered inside Magento's cms_block database table on 83 stores; 60 of those had carried an earlier version of the loader. The loader causes visitors' browsers to fetch instructions from attacker‑controlled servers, but the server first determines whether a request comes from a genuine customer or a security scanner and "gives scanners nothing," Sansec said.

Before October, the operator used the Keitaro traffic distribution system to choose per visitor whether to deliver a payload, redirect or return nothing. The loader that Sansec initially found on October 7 called the new domain directly and replayed code saved in the browser, producing persistence by rerunning the payload on later page loads even if the domain was down or blocked. An October 23 rewrite added browser fingerprinting, checking for signs of automation and collecting hardware details, screen size, time zone and language before the server selected its response.

When urlscan.io, a scanning service, loaded an infected store with an automated browser, Sansec observed no injected content — a practical demonstration of the attacker's scanner‑detection logic. Sansec has not obtained the final payload, and therefore the campaign's ultimate purpose remains unclear.

March wave and exploited CVEs

Sansec traced a March wave in which the attacker planted the loader on 471 stores within an hour by using webshells placed through PolyShell (CVE‑2026‑48356). Among 169 infected Magento 2 installations that were missing at least one core patch, Sansec found evidence that 102 showed file uploads consistent with both PolyShell and SessionReaper (CVE‑2025‑54236).

Those observations tie rapid mass compromise to known webshells and specific CVE identifiers identified by Sansec's analysis, indicating the campaign leverages post‑intrusion file uploads to deploy the loader at scale.

Persistence and reinfection: the Magento 2.4.7‑p10 case

Sansec's findings show that applying security patches alone did not always prevent reinfection. A fully patched store running Magento 2.4.7‑p10 picked up the newest loader on October 23, only an hour after passing a clean scan. Sansec had discovered a rogue admin account and a GSocket backdoor on that store in September, demonstrating that an existing foothold in the database or admin system can enable rapid re‑deployment of the loader even after patching.

Sansec warns that removing the injected script does not remove an attacker's write access to the database. As long as the underlying access remains, a compromised store can be reinfected while the original method of intrusion persists.

What this means for Magento merchants, security teams, and scanning services

  • Magento merchants: stores should be inspected for loader entries in CMS content — specifically in the cms_block table — and for unexpected admin accounts or backdoors that survive superficial cleanup.
  • Security teams and site operators: patching is necessary but not sufficient; Sansec's data tie reinfection to lingering backdoors and database write access, so comprehensive hunting for webshells, backdoors and rogue accounts is required along with credential rotation.
  • Automated scanning services: the campaign's browser fingerprinting and automation detection can hide injected content from scanners like urlscan.io, meaning scanning results may underreport active infections unless scanners emulate a realistic human browser environment.

Sansec's recommended remediation steps

Sansec advised merchants to search for the loader in CMS content, review admin accounts, and hunt for backdoors. After removing malicious content, operators should rotate database, admin and integration credentials and apply the latest Magento and Adobe Commerce security updates. Sansec emphasized that simply removing the injected JavaScript is insufficient if attackers retain write access to the database.

The campaign combines rapid, large‑scale compromise with an increasingly sophisticated loader that persists in victims' browsers and actively avoids detection. With 953 stores confirmed infected and the final payload still unknown, the unanswered technical question is not whether the attackers can hide from scanners, but what they intend to do once their code runs in customer browsers — and how long their retained database write access will allow them to return.

Source: Infosecurity Magazine / Sansec research