A criminal group has been parking a JavaScript loader inside Magento storefronts for fifteen months, and its newest domain went live on stores within a day of being registered. Sansec's count now stands at 953 stores touched since July 2025, mostly Magento and Adobe Commerce.

What happened

The current loader points at deepveindrilling.com, registered on 6 October 2026. By 24 October Sansec had found it in the static blocks of 83 stores. Sixty of those 83 were already carrying one of the group's four earlier loaders, some since October 2025, which means earlier cleanups removed the symptom and left the way back in.

The code lives in the cms_block table, the static content Magento renders into storefront pages. It fingerprints each visitor, checking for automation markers and collecting GPU, CPU, screen and timezone data, and only serves a payload to browsers that look like real shoppers. Sansec's monitoring has not yet captured the final payload, but earlier versions redirected visitors to crypto-themed sites, including one impersonating a hardware wallet brand.

The entry point in earlier waves was Magento's upload and session handling: CVE-2026-48356, the PolyShell upload flaw rated 9.3, and CVE-2025-54236, the SessionReaper input validation flaw rated 9.1. In March the operator injected the loader into 471 stores inside one hour after uploading webshells through PolyShell.

Who is affected

Magento Open Source and Adobe Commerce merchants, and anyone hosting or maintaining them.

• Across the campaign Sansec found the loader on 169 Magento 2 installs, all missing at least one core patch.
• 102 of those installs, about 60 percent, also carried files uploaded through PolyShell or SessionReaper.
• Patched stores are not automatically clean. One store on fully patched 2.4.7-p10 received the new loader an hour after a clean scan, because a rogue admin account and a backdoor were already in place.
• Adobe fixed PolyShell in APSB26-73 and SessionReaper in APSB25-88. Older release lines need those patches applied, not just the latest core.

What to do now

Treat it as an intrusion, not a spam injection. Removing the script alone does not remove the attacker's ability to write to your database.

• Query the cms_block and cms_page tables for the loader patterns Sansec published, and check update_time to see when the attacker last wrote.
• Look for webshells in the media upload directories, unfamiliar admin_user rows, and stray PHP files such as accesson.php.
• After cleanup, rotate the database password, admin passwords and API integration keys, then apply APSB26-73 and APSB25-88.
• Block execution inside pub/media/custom_options/ at the web server, and put a WAF rule in front of the guest-cart REST endpoints.

What this means for South African businesses

Online stores are usually the one system a local SME cannot take offline for a week, which is exactly why this campaign keeps working: the loader is small, the site stays up, and nobody notices until card data or wallet credentials surface. Two things matter more than the malware itself. First, a store that was compromised before is still compromised, so a clean scan is not proof of anything. Second, patching a store that already has a backdoor buys nothing. My judgement is that most local Magento and Adobe Commerce shops sit with a hosting partner who will run the patch but will not hunt the backdoor, and that gap is where this campaign lives.

Source: Sansec Forensics Team.

Also on the blog

• PHP2Shell: CVE-2026-109618 RCE confirmed on a live PHP 8.4.26 server
• CVE-2026-110447: web shells planted on Nextcloud through Collabora's CODE app

Next step: If this is on your network or a client's, ask Matthews Enterprises to check exposure.