Magento CMS Block Loader: How It Hides From Scanners on 953 Stores

Sansec reports that a criminal group has used Magento CMS block malware to infect 953 stores since July 2025. The malware is a small JavaScript loader hidden in the content of CMS blocks, and most of the stores run Magento. Its newest loader address, deepveindrilling[.]com, appeared in the blocks of 83 stores in October 2026.

On 23 October the operator rewrote those blocks again. The new loader fingerprints each visitor’s browser, so security scanners get an empty reply and only real shoppers get a payload. Sansec published the research on 24 October 2026 and does not name the group.

Last updated: 27 October 2026. We update this page if Sansec or Adobe publish new findings.

How Does a Loader in a CMS Block Reach Shoppers?

Magento keeps static page parts in the cms_block table. Sansec says the loader sits in the content field of that table. Its eComscan scanner found it there on 148 server installs over the campaign, and never in core_config_data or in theme files.

The first October version used two scripts. Sansec’s crawler found it on 74 stores by the end of 8 October. The first script reads a localStorage key named fpCode. If the key is set, the script puts the stored code in the onclick attribute of an invisible div and clicks it. The browser then runs the code as an event handler, without eval().

Nothing in the block writes fpCode, so the script from the loader domain has to set it. A visitor who received the payload once runs it again on every later page view, even when the domain is offline or blocked. Sansec notes that the March version deleted its stored payload after one run.

What Changed in the Rewrite of 23 October?

The loader appeared on 9 more stores on 23 October, and all 71 stores that Sansec re-crawled by 24 October run the new version. It replaces the plain script tag with an inline loader. That loader sends a browser fingerprint to the operator’s server, and the server decides what comes back.

The fingerprint flags automated browsers through navigator.webdriver, Selenium globals and the cdc_ properties of ChromeDriver. It also adds the GPU name from WebGL, CPU cores, memory, screen size, time zone, languages and client hints.

When urlscan.io loaded an infected store with an automated Chrome browser, the server answered HTTP 200 and Sansec found no added content in the page. Sansec has not captured the final payload of this version yet, so we cannot say what it does to a shopper.

Earlier versions relied on Keitaro, a commercial ad tracker that doubles as a traffic distribution system. The second script sent the referrer, page title and query string to a Base64 encoded address. The system then decided per visitor whether to return a payload, a redirect or nothing. When Sansec asked as a Windows desktop visitor on 24 October, it got a statement that does nothing and a cookie that marks the visitor for 24 hours.

The new loader drops Keitaro and does the bot filtering itself. Older stages did deliver follow-up pages: on 12 December 2025 a logged-in customer of an infected store received a script that loaded two further addresses. One of them misspells the Ledger crypto wallet brand.

How Many Domains Has the Operator Used?

Sansec counts five loader domains in 15 months, plus two more that ran on a few stores. We leave the older addresses out of the table on purpose. They are in Sansec’s indicator list, and the dates and counts show the pattern.

The counts add up to more than 953, so many stores carried more than one loader over time. That is our reading of Sansec’s numbers. Sansec says 60 of the 83 stores on the newest domain already ran an earlier loader, 34 of them since October 2025.

Two of the old domains expired and were registered again in May 2026, and both now use the nameservers of a domain parking service. Between August and October 2026 Sansec still found their loaders on 9 and 6 stores. Visitors of those stores send their referrer and page title to the new domain owner, and their browsers run any script it returns.

Sansec Watch, the company’s CSP monitoring service, received reports of visitors’ browsers loading all four earlier domains. For the domain first seen in June 2026 the reports reached about 52,000.

How Did the Attackers Get In?

Sansec says the October rewrites used no new vulnerability, because 60 of the 83 stores were already infected. Earlier waves point to Magento file upload flaws. In March the operator injected the loader into 471 stores in one hour, after uploading web shells through PolyShell (CVE-2026-48356).

The Sansec PolyShell advisory describes a flaw in the REST API that lets unauthenticated attackers upload executable files through cart item options. The files land in pub/media/custom_options/quote/. The NVD record lists it as an unrestricted upload of a file with a dangerous type, with a CVSS 3.1 score of 9.3.

The second flaw is SessionReaper (CVE-2025-54236). The NVD record calls it improper input validation that allows session takeover without user interaction, with a CVSS score of 9.1. It shows a CISA KEV addition date of 24 October 2025.

Across the campaign, eComscan found the loader on 169 Magento 2 installs that miss at least one core patch. Of these, 102 (60%) also have files uploaded through PolyShell or SessionReaper. On 3,024 comparable installs with a different skimmer the rate is 32%.

One store on Magento 2.4.7-p1 had PolyShell web shells disguised as PNG images in the upload folder, next to the loader in a CMS block. The block switched to the new domain on 7 October, and the store still lacks APSB26-73, Adobe’s PolyShell fix for supported release lines.

Patching alone did not keep the operator out. A store on Magento 2.4.7-p10 with no missing core patches got the new loader at 16:46 UTC on 23 October, one hour after a clean scan. eComscan had found a rogue admin account on it on 16 September and a GSocket backdoor on 24 September.

Public tooling exists for the first flaw. A GitHub search for Magento and PolyShell on 27 October 2026 returns 14 repositories. Most of them describe patches, checks or protection modules.

At least three others advertise exploit code. One, created on 8 April 2026, calls itself a Magento RCE exploitation toolkit in its README and describes an unauthenticated upload through the REST API cart. Another, created on 15 July 2026, calls itself an exploit. These are the authors’ claims, and we did not run any of the code.

How Can You Check a Store for the Loader?

Sansec advises searching CMS content for code patterns, because the domains are often Base64 encoded. Run this query, then repeat it on the cms_page table. Add your table prefix if the store uses one.

SELECT block_id, identifier, update_time FROM cms_block
WHERE content LIKE '%fpCode%' OR content LIKE '%se_referrer%'
   OR content LIKE '%localStorage.getItem%';

The update_time column shows the attacker’s most recent write. After you remove the scripts, nothing on the store reads fpCode any more. Sansec warns that deleting the script does not remove the attacker’s database write access, so the cleanup continues.

Why Do Scanners Keep Missing It?

The loader is built to look clean to the tools that check storefronts. An automated scan gets HTTP 200 and no added content, as the urlscan.io run showed. Our reading is that a clean scan is weak evidence for a store that was infected before. Check the database and the file system, not only the rendered page.

Sansec’s report carries the full list of indicators of compromise, and matching it against web and proxy logs is a quick extra check. The final payload is not known yet. Sansec files the research under its Magecart tag, the name for scripts that steal card data at checkout, which our post on Magecart e-skimmer attacks on restaurant ordering platforms explains.