Malware in Your Magento CMS Blocks: What the deepveindrilling.com Loader Does

Sansec reports that a criminal group has hidden a small loader in the CMS blocks of 953 mostly Magento stores since July 2025. Because the loader lives in the database, a file scan misses it, and the group's server shows automated scanners a clean page. Deleting the script does not close the way in. Ask your developer to search CMS blocks and pages, then find how the attacker got in.

What did Sansec find?

Sansec found a new address, deepveindrilling.com, in the CMS blocks of 83 online stores, nearly all on Magento. The domain was registered on October 6, 2026, and the first stores loaded it the next evening. It is the fifth address of a campaign Sansec has tracked since July 2025, and the group moves to a new one every few months (Sansec, October 24, 2026).

Most of the 83 were old victims. Sixty of them already ran an earlier loader from the same operator, 34 of them since October 2025. Across the whole campaign, Sansec counts 953 stores.

A CMS block is a piece of stored content that Magento builds into storefront pages, such as a banner or footer text. That makes it a convenient place to hide a few lines of code that run for every visitor.

Why do scanners miss it?

Two reasons. It sits in the database, and it checks who is asking before it sends anything.

Sansec's scanner found the loader in the cms_block table, never in theme files or in a configuration table. A scan that reads files and templates can pass over it. The loader also sends the visitor's browser fingerprint to the group's server, including signs of an automated browser. The server then picks the response. When urlscan.io loaded an infected store with an automated Chrome browser, it got a normal page, and Sansec found no added content.

There is a second trick. For visitors the server does send a script to, the loader stores that code in the browser and runs it again on every later page view, even if the group's domain is later offline or blocked.

How did the group get in?

Not with a new flaw this time. Sansec says the October rewrites needed none, because most of the stores were already infected. Earlier waves point to Magento file upload flaws: in March 2026 the group put its loader on 471 stores in one hour after uploading webshells through PolyShell (CVE-2026-48356).

Across the campaign, Sansec found the loader on 169 Magento 2 installs missing at least one core patch. Of those, 102 (60%) also had files uploaded through PolyShell or SessionReaper (CVE-2025-54236). On 3,024 comparable installs with a different skimmer, the rate was 32%.

Patching alone is not a clean bill of health. Sansec found one store on Magento 2.4.7-p10 with no missing core patches that received the loader on October 23, one hour after a clean scan. It already had a rogue admin account and a backdoor from September.

What happens when a domain it used expires?

Someone else can take it over. Two of the group's older domains expired and were registered again in May 2026, and Sansec still found 15 stores loading from them between August and October. Those stores' visitors now send their referrer and page title to the new owner, and their browsers will run any script that owner returns.

The lesson applies to every store, Magento or not. An old script tag that points at a domain nobody remembers can outlive the vendor behind it. Our audit guide is a way to find those.

What should a store owner do this week?

You do not need to read the database yourself. Hand your developer this list.

1. Search CMS blocks and pages for the loader code (queries below).
2. Look for how the attacker got in, not just what they left. Check admin accounts you do not recognize, unfamiliar files, and unfamiliar processes.
3. Install the fixes for PolyShell and SessionReaper. Sansec names Adobe's APSB26-73 for PolyShell and APSB25-88 for SessionReaper.
4. After cleanup, change the database, admin and API integration passwords.
5. Check your checkout page for scripts you did not add, and compare it week to week. Here is what to watch and how often.
6. Tell your payment processor if you suspect card theft.

What does your developer need to run?

These come from Sansec's report. Search your CMS content for the loader code, since the domains are often encoded and the code patterns are easier to find:

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 query on cms_page, adding your table prefix if you use one. The update_time column shows the attacker's most recent write. Then look for uploaded files that should not be there:

find pub/media/custom_options/ pub/media/customer_address/ -type f ! -name '.htaccess'
find . -name 'accesson.php' -type f

Sansec lists the loader's web addresses in its report, including deepveindrilling[.]com, additionalver[.]com, lanhd6549tdhse[.]top, neswnsssn[.]click and manulfie[.]click (written with the dots bracketed so they are not live links). Remember the earlier point: the domains may be encoded, so search for the code patterns above as well.

Was this a card skimmer?

Not confirmed. Sansec had not captured this loader's final payload when it published. In an earlier wave, a script served to a logged-in customer pointed to a lookalike of a crypto-wallet brand's site. Either way, a script you did not add on a store that takes payments is worth treating as serious. For the card-theft version of the same pattern, see what a Magecart attack is and the Magento zero-day StyleSmuggler.

Keep watching after the cleanup

Removing a script closes nothing if the way in stays open. Checking once shows you today.

This is your store today. App updates, theme edits and new agency work change it, usually without anyone telling you. Run a free check, verify your domain, and keep it running.

Sources: Sansec, "deepveindrilling.com: Magento CMS block loader hits 953 stores," October 24, 2026.