Dutch e-commerce security firm Sansec says an unknown group has planted a small JavaScript loader on 953 online stores, most of them running Magento, in a campaign active since July 2025. The loader sits in the store’s cms_block database table, which Magento uses for static content such as headers, footers and banners. When a shopper opens an infected store, their browser asks the group’s server what to do next. The server first checks whether the visitor is a real shopper or a security scanner, so scanners get nothing back. Sansec says the final payload is not known.
The group has used five loader domains so far, moving to a new one every few months. The newest, deepveindrilling.com, was registered on October 6, 2026, and appeared in the CMS blocks of 83 stores from the next evening; 60 of those already carried an earlier loader. Sansec describes two versions in October. The first stores a payload in the visitor’s browser (localStorage), so it keeps running on later page views even if the domain goes offline or is blocked. The second sends a browser fingerprint that filters out automated browsers. Sansec also reports that old domains the group let expire were re-registered by others, so visitors to the stores still using them send their referrer and page title to the new owner.
On how the stores were breached, Sansec says the October rewrites used no new vulnerability, because most 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 webshells through PolyShell (CVE-2026-48356). Across the campaign, Sansec found the loader on 169 Magento 2 installs missing at least one core patch, and 102 of them also had files uploaded through PolyShell or SessionReaper (CVE-2025-54236). Patching alone is not enough, though: a store on Magento 2.4.7-p10 with no missing core patches was injected one hour after a clean scan, and Sansec had earlier found a rogue admin account and a backdoor on it.
How to check if you’re affected
Affected products are Magento and Adobe Commerce stores, mostly Magento 2, and in particular installs that have not applied Adobe’s PolyShell fix (APSB26-73) or the SessionReaper fix (APSB25-88). Sansec’s check is a database query for the loader code, run on both cms_block and cms_page (add your table prefix 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%';
Sansec says update_time shows the attacker’s most recent write, and that removing the script does not remove the attacker’s access. It also advises looking for files in pub/media/custom_options/ and pub/media/customer_address/, searching for a file named accesson.php, reviewing the admin_user table for accounts you do not recognise, and changing database, admin and API integration passwords after cleanup. Sansec’s full indicator list is in its report. Sansec sells its own scanner and firewall products, which it mentions alongside this advice; the checks above need neither.