953 Magento Stores Got a CMS Block Loader Named deepveindrilling.com
Sansec just published the latest chapter of a Magento infection campaign that has been quietly rewriting CMS blocks since July 2025. the newest loader domain is deepveindrilling.com, registered October 6, 2026, sitting behind Cloudflare, answering only to real shopper browsers so scanners get a polite 404. 953 stores across the whole campaign. 83 on the new domain. and deleting the script does nothing about the attacker who can still write to your database.
cms_block table, never in core_config_data or theme files. Earlier waves abused PolyShell (CVE-2026-48356) and SessionReaper (CVE-2025-54236) for file upload. 60 of the 83 stores on the new domain were already infected with a prior loader. Patched stores still get hit through rogue admin accounts and GSocket backdoors left behind.what the loader actually does
the injected JavaScript makes the visitor’s browser ask the operator’s server what to do next. the server fingerprints the visitor first. scanners, bots, and researchers get nothing. real shoppers get a payload. Sansec has not yet captured the final payload on the deepveindrilling wave, but earlier versions of the same loader served scripts from crypto-themed domains, including one mimicking Ledger. that is the classic Magento skimmer pattern: steal cards and wallets from people who thought they were buying shoes.
the domain’s front page returns 404. it only answers script requests that look like they came from an infected storefront. Cloudflare in front. fingerprinting behind. your eComscan job that hits the origin from a datacenter IP sees a clean site. your customers do not.
how the stores were breached
the October rewrite wave did not need a new vulnerability, because most of those 83 stores were already owned. the March wave was uglier: 471 Magento stores got the loader in about an hour after webshells went in through PolyShell. across the campaign, Sansec found the loader on 169 Magento 2 installs missing at least one core patch, and 102 of those (60 percent) also had files uploaded through PolyShell or SessionReaper. on a comparable set of stores with a different skimmer, that rate was 32 percent. correlation is not causation, but it is a very loud hint.
patched stores get hit too. Sansec cites a Magento 2.4.7-p10 box with no missing core patches that received deepveindrilling.com at 16:46 UTC on October 23, one hour after a clean scan. eComscan had already found a rogue admin account on September 16 and a GSocket backdoor on September 24. the lesson writes itself: patching the CVE does not evict the human who already has an admin account and a reverse shell.
how to check your store
- search
cms_blockcontent fordeepveindrilling.com,manulfie.click,neswnsssn.click,lanhd6549tdhse.top, andadditionalver.com. - audit every Magento admin account. anything you did not create, disable and investigate.
- hunt for webshells under
pub/media(Sansec saw PolyShell shells disguised as PNGs underpub/media/custom_options/quote/) and for GSocket-style backdoors. - confirm you are on a build that includes APSB26-73 (PolyShell) and the SessionReaper fixes. then assume that is necessary but not sufficient.
- rotate every admin password, every API key, every integration token, and review cron and connected apps.
the boring, correct response
if any of those loader domains appear in your CMS blocks, the attacker can write to your database. removing the script is hygiene, not remediation. treat the box as compromised, rebuild from a known-clean state where you can, rotate credentials, and put a CSP monitor on the storefront so the next loader domain lights up a pager instead of a Sansec blog post three months later.
e-commerce attackers do not need to be clever when Magento admins leave old upload bugs and forgotten admin accounts lying around. deepveindrilling.com is just the current name on the same long game.
if your storefront has been quiet for a year, that is not the same thing as clean. get it checked. Book a slot with Dark Edge Consulting.
