Threat intel

Magento CMS block loader hits 953 stores, hides from scanners

By Yaali. October 28, 2026, 6 min read, Threat intel, Vulnerabilities, Patching.

Sansec tracked a JavaScript loader in Magento's cms_block table on 953 stores since July 2025. How it dodges scanners, the SQL to find it and how to clean up.

Sansec's forensics team published research on October 24 about one operator who has planted a JavaScript loader on 953 online stores since July 2025, nearly all of them Magento or Adobe Commerce. The loader lives in the cms_block database table, which holds the static content blocks Magento renders into storefront pages, so it never shows up in theme files or the core_config_data settings where skimmer hunts usually start. The newest loader domain, deepveindrilling.com, was registered on October 6 and was on 83 stores within weeks.

If you run Magento, this affects you whether or not you are fully patched. Sansec saw at least one store with no missing core patches pick up the loader on October 23, an hour after a clean scan, and 60 of the 83 newest victims had already carried one of the operator's earlier loaders, 34 of them since October 2025. The loader checks whether each visitor is a real shopper or an automated scanner and serves scanners nothing, which is how it has stayed on some stores for a year.

How it works

A CMS block is a piece of HTML that a store admin edits in the backend (Content, Elements, Blocks) and Magento drops into pages, such as a footer or a promo banner. Whatever is in cms_block.content goes to every browser that loads a page using that block. An attacker who can write one database row gets script on the storefront without touching a single file, which is why file integrity checks miss it.

The October 7 version of the block carried two scripts. The first reads a value called fpCode from the visitor's browser localStorage. If it is set, the script writes the stored code into the onclick attribute of an invisible element, clicks it and removes it. That runs arbitrary code without calling eval(), which some detection rules look for. Nothing in the block sets fpCode; the payload served on an earlier visit does, and because it is never deleted, it runs again on every later page view even if the loader domain is offline.

The second script asked the operator's server what to serve. Before October, that server was Keitaro, a commercial ad tracker that also works as a traffic distribution system (TDS): it takes the referrer, page title and query string, sent to a Base64-encoded campaign URL with an se_referrer parameter, and decides per visitor whether to return a payload, a redirect or nothing. When Sansec requested the additionalver.com script on October 24 as a Windows desktop visitor, it got back QWE=123;, a statement that does nothing, plus a cookie marking the visitor for 24 hours.

On October 23 the operator rewrote the blocks again. The new inline loader drops Keitaro and does the bot filtering itself. It collects navigator.webdriver, Selenium globals and ChromeDriver cdc_ properties (the markers automated browsers leave), plus the WebGL graphics card name, CPU core count, memory, screen size, time zone, languages and client hints, and sends that fingerprint to deepveindrilling.com/?s=49b7ca5f&fp=. When Sansec loaded an infected store through urlscan.io's automated Chrome, it got an HTTP 200 page with nothing added. Sansec has not yet captured the final payload of the new version.

What attackers are doing

The operator rotates domains every few months: manulfie.click from July 9, 2025 (863 stores), neswnsssn.click from December 12, 2025 (494), lanhd6549tdhse.top from March 30, 2026 (355), additionalver.com from June 8 (246) and deepveindrilling.com from October 7 (83). The totals overlap because stores were moved from one domain to the next. Sansec's eComscan found the loader in cms_block on 148 server installs over the campaign.

Earlier payloads Sansec did capture pointed at crypto fraud. On December 12, 2025, a logged-in customer on one store was served a script from manulfie.click that loaded crypto-insider.top, then leqdger.click, a misspelling of the Ledger hardware wallet brand. Sources do not report card data being stolen by this campaign, so treat the end goal of the October loader as unknown.

Entry came mainly through Magento file upload flaws. PolyShell, CVE-2026-48356, is an unrestricted file upload in the REST API that Adobe rates Critical with a CVSS score of 9.6 and fixed in bulletin APSB26-73 on July 14, 2026. On March 30, 2026, the day lanhd6549tdhse.top first appeared, a PolyShell wave hit 471 stores in one hour. SessionReaper, CVE-2025-54236, fixed in APSB25-88, also left uploaded files on infected stores. One Magento 2.4.7-p1 store still lacking APSB26-73 had PolyShell webshells disguised as PNG images in pub/media/custom_options/quote/, next to the loader. The 2.4.7-p10 store that Sansec found missing no core patches, infected on October 23, had earlier had a rogue admin account (found September 16) and a GSocket backdoor, a tool that gives remote shell access (found September 24). Up-to-date code did not remove access the attacker already held.

What to do

Search the CMS tables. Sansec's query, with your table prefix added if you use one:
```
SELECT block_id, identifier, update_time FROM cms_block
WHERE content LIKE '%fpCode%' OR content LIKE '%se_referrer%'
OR content LIKE '%localStorage.getItem%';
```
Run the same against cms_page (use page_id). The domains are often Base64 encoded, so also look for long Base64 strings and for the encoded form of each domain below. update_time shows the attacker's last write and helps date the intrusion.
Find the way in. List uploads that should not be there with find pub/media/custom_options/ pub/media/customer_address/ -type f ! -name '.htaccess', and look for find . -name 'accesson.php' -type f. Check admin_user for accounts nobody created and the process list for unknown long-running processes such as GSocket.
Remove the injected blocks and every backdoor in the same window. Sansec warns that a store loading any of these domains may still give the attacker database write access after the script is gone. When you are done, nothing on the store should read fpCode.
Rotate the database password, every admin password and all API integration tokens.
Patch. APSB26-73 fixes PolyShell; the fixed builds are 2.4.9-2026-jul, 2.4.8-2026-jul, 2.4.7-2026-jul and 2.4.6-2026-jul for Magento Open Source and Adobe Commerce (Commerce also has 2.4.5 and 2.4.4 lines), and B2B 1.5.3-2026-jul and its siblings. Install APSB25-88 for SessionReaper if you have not. If the upgrade has to wait, put a web application firewall (WAF) rule in front of the REST upload paths; Sansec points to its own Shield product for this.

Block these domains at the proxy or Content Security Policy (CSP) and search for them in CMS content and access logs: deepveindrilling.com, additionalver.com, lanhd6549tdhse.top, hdfdsi84j3h.top, neswnsssn.click, manulfie.click, c85grt98sd.com, crypto-insider.top and leqdger.click. manulfie.click and neswnsssn.click now sit on parking nameservers but can still receive visitor data and return scripts.

Where skimmer checks fall short

This campaign beats two common habits: scanning files instead of the database, and checking a storefront from a headless browser. Monitoring should diff cms_block and cms_page content and alert on any new <script>, and checkout testing should include a real, non-automated browser. A strict CSP script-src list would have stopped the browser from fetching from the loader domain at all.

We test Magento stores for injected content and the upload flaws behind it in web penetration testing, and watch for changes like these in security operations. If a query above returns rows, open the chat and Yaali, our AI agent, will pass your question to an engineer.

Sources: Sansec, The Hacker News, Security Affairs, SecurityWeek, Adobe APSB26-73, Meetanshi (APSB26-73 versions).