JavaScript loader infects 953 Magento stores, Sansec says

Dutch e-commerce security firm Sansec reports that a single criminal group has planted a malicious JavaScript loader on 953 Magento stores, the latest tally in a campaign running since mid-2025. The finding is in Sansec's post "deepveindrilling.com: Magento CMS block loader hits 953 stores," published to its research feed; that control domain is the thread Sansec used to count current infections. SecurityWeek covered the findings on October 26.

What the loader does

The injected code sits in Magento CMS pages and static blocks and fetches a second-stage payload from an attacker domain. Before serving it, the loader fingerprints each visitor — referrer, page title, query parameters — so the payload reaches real shoppers and not researchers or scanners poking at the site. Sansec did not capture the payload itself, so the exact theft mechanism is not confirmed, but the placement and targeting match a client-side skimming operation.

The group rotates domains to stay ahead of blocklists. Loader hosts tied to the campaign include:

deepveindrilling.com
additionalver.com
lanhd6549tdhse.top
manulfie.click
neswnsssn.click

Sansec says deepveindrilling.com alone appeared on 83 stores, 60 of which had already run earlier loader versions, and that it observed roughly 52,000 visitor browsers loading additionalver.com.

How stores got hit

The operators exploit known, unpatched Magento and Adobe Commerce flaws to inject the loader. Per SecurityWeek's account of Sansec's research, entry points include SessionReaper (CVE-2025-54236), the unauthenticated RCE Sansec has tracked into active exploitation, and the PolyShell file-upload flaw, which Sansec says hit 471 stores in a single hour back in March. On at least one compromised store, Sansec also found a rogue administrator account and a GSocket backdoor.

Action checklist

1. Search your Magento/Adobe Commerce CMS pages and static blocks for injected <script> loaders referencing the domains above or any unfamiliar external host.
2. Confirm you are patched for SessionReaper (CVE-2025-54236) and PolyShell; unpatched storefronts are the entry point, not just the symptom.
3. Audit admin accounts for unexpected users and check for backdoors (GSocket and similar) and cron-based re-infection.
4. After cleanup, rotate all admin and integration credentials and redeploy from a known-good baseline — removing the script without closing the entry point invites re-injection.

Context

This is the same cycle Magecart has run for a decade: a known storefront RCE begets mass injection, the skimmer group rotates infrastructure, and stores that skipped a patch pay the rent. It follows Adobe's recent CVSS 10 Magento template RCE — a reminder that e-commerce platforms sit at the intersection of high patch urgency and low patch discipline. The fingerprinting step is the operational tell here: the group optimizes for staying unseen by defenders while still cashing out against shoppers.