A Magento Loader Hides From Scanners. One Query Finds It

What Sansec Found

On October 24, 2026, the e-commerce security firm Sansec published research on a loader that one operator has been planting in online stores since July 2025. It has reached 953 stores so far, most of them on Magento. The code is not in theme files or in the Magento codebase. It lives in the database, inside CMS blocks, the small pieces of content Magento renders into storefront pages.

The newest version loads from deepveindrilling.com, a domain registered on October 6. Sansec found it in the CMS blocks of 83 stores. Sixty of those already ran one of the operator's earlier loaders, 34 of them since October 2025, so for many stores this is a long-term tenant and not a fresh break-in. On October 23 the operator rewrote the blocks with a version that fingerprints each visitor, and that version turned up on nine more stores.

The encouraging part is that this one is easy to look for once you know where it lives. A store owner or a developer can check for it with one SQL query and two find commands, and the cleanup steps are well understood.

Why Scanners Miss It

Most store checks look at files. A file integrity check compares the code on disk with a known-good copy, and a theme review looks at what developers committed. Neither sees a CMS block, because blocks are rows in the cms_block table, edited through the admin panel or straight in the database. Over the course of the campaign Sansec's eComscan found the loader in cms_block on 148 installs, and never in core_config_data or in theme files.

External scanners have a different problem. The loader asks a remote server what to do, and the server decides per visitor. The October 23 version sends a browser fingerprint first. It looks for signs of automation, such as navigator.webdriver, Selenium globals and the cdc_ properties ChromeDriver leaves behind, and it collects the graphics card name, CPU cores, memory, screen size, time zone, languages and client hints. A browser that looks automated gets nothing back. When urlscan.io loaded an infected store with automated Chrome, the page came back with HTTP 200 and no added content.

Earlier versions did the same job with Keitaro, a commercial traffic distribution tracker built for advertising. Keitaro chose per visitor between a payload, a redirect and nothing at all. When Sansec tested it as a Windows desktop visitor on October 24, it returned a do-nothing statement, QWE=123;, and set a cookie for 24 hours. The newest domain drops Keitaro and does the filtering inside the loader itself.

So an outside scan of an infected storefront can come back clean. That says nothing about what a real shopper receives.

The Part That Outlives the Domain

The loader has two parts. The first is a short inline script that reads a key named fpCode from the visitor's localStorage. If the key holds anything, the script puts that value into the onclick attribute of a hidden element, clicks it and removes the element. All of this runs without eval(), which keeps it away from the pattern most detectors look for first.

Nothing in the block itself writes fpCode, so the remote server must set it. Once a shopper has received a payload, it stays in their browser and runs again on every later page view of that store, even when the attacker's domain is offline or blocked. The March version deleted its stored payload after one run. The current one keeps it.

That changes how a fix works. Blocking the domain at a firewall or a CDN does not reach shoppers who already carry the payload. Removing the injected scripts does, because after that nothing on the store reads fpCode and the stored value sits in the browser unused.

What It Delivers

Sansec has not captured the final payload of the current version. The payloads it did record came from the Keitaro stage in December 2025, scripts that loaded leqdger.click, a misspelling of the crypto wallet brand Ledger, and crypto-insider.top. That points to crypto-related fraud aimed at shoppers. Sansec does not describe card theft in this campaign.

For the store owner the payload matters less than the access. The operator can write to the store's database, and the loader lets them change what shoppers see at any moment without touching the store again.

How the Attackers Got In

Sansec looked at 169 infected Magento 2 installs that were missing at least one core patch. On 102 of them, 60%, files had also been uploaded through PolyShell or SessionReaper. On 3,024 comparable installs infected with a different skimmer, the rate was 32%. Those two upload flaws are the likely way in for most of these stores.

• PolyShell, CVE-2026-48356. An unrestricted file upload through Magento's REST API, where a cart item's custom option of type file accepts an uploaded file. Adobe rates it critical at CVSS 9.6 with no login required, although its score assumes some user interaction. Sansec disclosed it in March 2026 and soon reported mass exploitation with image files that also carry PHP code. Adobe's fix for production releases came in APSB26-73 on July 14, 2026. Uploaded files land in pub/media/custom_options/quote/, and one infected store had webshells there disguised as PNG images.
• SessionReaper, CVE-2025-54236. An input validation flaw rated CVSS 9.1, again with no login required, fixed in APSB25-88 on September 9, 2025, with a hotfix for 2.4.4 to 2.4.7. Adobe later confirmed it was being exploited in the wild and raised it to priority 1 on October 24, 2025.

Patching does not remove someone who is already in. One store with the loader ran Magento 2.4.7-p10 and had no missing core patches. eComscan had earlier found a rogue admin account and a GSocket backdoor on that server, which is how an operator keeps access after the holes are closed. A store that was unpatched during the PolyShell wave in March and patched later still needs the checks below.

How to Check Your Store

Run these against the store's database, ideally with a read-only user. If your tables use a prefix, add it to the table names.

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

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

These are Sansec's patterns. fpCode and se_referrer are specific to this operator. A match on localStorage.getItem alone can be legitimate, since some themes and page builders use it, so read the block before you decide. The update_time column shows the most recent write, which for an infected block is the attacker's.

Two more queries help. The first lists the blocks that changed most recently, and the second searches for the operator's domains directly.

SELECT block_id, identifier, update_time FROM cms_block ORDER BY update_time DESC LIMIT 20;

SELECT block_id, identifier FROM cms_block
WHERE content REGEXP 'deepveindrilling|additionalver|lanhd6549tdhse|neswnsssn|manulfie|hdfdsi84j3h|c85grt98sd';

Then check the two upload folders and look for the file name Sansec lists. Run this from the Magento root.

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

A store that sells products with file options will have real uploads in custom_options, so look at what the files are. An image that contains PHP code is not an image, and the grep line finds those.

Finally, look at who can log in to the admin panel.

SELECT user_id, username, email, created, logdate, is_active FROM admin_user ORDER BY created DESC;

An account nobody on the team recognizes is a finding on its own, whatever the other checks say. Look at the processes running under the web server's user as well, because the 2.4.7-p10 store had a backdoor running there.

If You Find It

Work in this order. Removing the script first only hides the symptom.

1. Save a copy of the infected rows and any suspicious files before you change anything. You will need them to work out the timeline.
2. Find the way in. Remove webshells from the upload folders, rogue admin accounts and unfamiliar processes. As Sansec puts it, deleting the script does not remove the attacker's access to the database.
3. Remove the injected scripts from cms_block and cms_page, then run bin/magento cache:flush and purge Varnish or the CDN if you use them. Block output is cached, and without a flush shoppers keep getting the old page.
4. Change the database password, the admin passwords and the API integration credentials, as Sansec advises.
5. Install the fixes. APSB26-73 covers PolyShell and APSB25-88 covers SessionReaper. Adobe's patch releases are cumulative, so a store on the July 2026 builds or newer, named 2.4.x-2026-jul and later, has both.

Closing the upload folders at the web server is cheap insurance against the next upload flaw. On nginx, deny direct access to the folders that hold customer uploads, reload, and confirm that a request to them returns 403.

location /media/custom_options/ { deny all; }
location /media/customer_address/ { deny all; }

This stops an uploaded file from being reached and run through the browser. It does not stop the upload itself, so the patch is still needed.

What This Means for Store Owners

Being patched and being clean are two separate checks. The first tells you whether the next attacker can get in, the second whether one already did. For this campaign a storefront scan answers neither, because the loader shows scanners an empty page.

The database check above takes a few minutes. Running it after every patch cycle, and after any wave of attacks on a Magento upload flaw, catches an injection like this one early, while it is still a cleanup job.

Where It Fits

Adobe's October security update is the current release to install, and our write-up of the StyleSmuggler zero-day walks through the September attack and its hotfix. If you want a Magento store checked for this loader and brought up to date, that is part of our security and compliance work.

Sources

• Sansec: Magento CMS block loader hides from scanners (October 24, 2026)
• The Hacker News: Hackers infect 953 online stores (October 26, 2026)
• Adobe: Security update available for Adobe Commerce, APSB26-73
• Adobe: Security update available for Adobe Commerce, APSB25-88
• The Hacker News: Magento PolyShell flaw (March 20, 2026)