Magento Malware Campaign Hits 953 Stores and Hides From Scanners

Sansec reports that a single Magento malware campaign has infected 953 online stores since July 2025, and its newest loader serves nothing to automated scanners. If your shop was hit once, the attacker has probably been back, and a clean scan result will not tell you.

What is the Magento malware campaign using deepveindrilling.com?

It is a long-running operation that plants a small loader script in Magento CMS blocks. Each shopper’s browser then fetches further instructions from the attackers’ server. The e-commerce security firm Sansec has tied 953 infected stores to the group since July 2025, most of them running Magento. It first reported the campaign in March 2026 as the PolyShell mass attack.

deepveindrilling.com is the group’s fifth loader domain. It was registered on 6 October 2026, and Sansec’s eComscan scanner first saw the new loader at 21:54 UTC the next day. By the end of 8 October, Sansec’s crawler had found it on 74 stores.

On 23 October the operator rewrote the blocks again. The loader reached nine more stores, for a total of 83, almost all Magento, and switched to a new inline format. Every one of the 71 stores Sansec had re-crawled by 24 October was running the new version.

Most were not new victims. Of the 83, 60 had already loaded one of the group’s earlier scripts, and 34 had done so since October 2025. That is about 72% repeat infections. The operator keeps returning to stores it already controls and rewriting the same database content.

How does the loader hide from security scanners?

The attackers’ server decides, visitor by visitor, whether to send anything, and automated browsers get nothing. deepveindrilling.com sits behind Cloudflare and returns a 404 on its front page. It answers script requests only from visitors of infected stores, so anyone who browses to it directly sees what looks like a dead site.

The loader starts by fingerprinting the browser. It checks for automation markers: the navigator.webdriver flag, Selenium globals and the cdc_ properties that ChromeDriver leaves behind. Then it collects device traits:

• WebGL GPU name
• CPU core count and memory
• Screen size
• Time zone and languages
• Client hints

Together, these values separate a headless scanner in a data center from a shopper on a laptop. They also let the operator choose which humans receive a payload.

The filter works. When urlscan.io loaded an infected store with automated Chrome, it got HTTP 200, and Sansec found no added content in the page. Server logs and static HTML scans look normal, yet selected shoppers can still receive attacker code. A green result from an uptime monitor or a one-off URL scan does not clear a store.

From Keitaro to an inline loader

Before October 2026, the second script was the “Script (async)” integration of Keitaro, a commercial ad tracker that doubles as a traffic distribution system. The script sent the referrer, page title and query string to a base64-encoded address carrying a se_referrer parameter. Keitaro then decided per visitor whether to return a payload, a redirect or nothing.

When Sansec requested the additionalver.com script as a Windows desktop visitor on 24 October, it received a harmless placeholder script plus a cookie that marked the visitor for 24 hours.

The 23 October version drops Keitaro. It replaces the plain script tag with an inline loader that sends the fingerprint straight to deepveindrilling.com, so the bot filtering now happens inside the loader itself.

What did earlier stages serve?

Sansec has not yet captured the final payload that real shoppers receive in the current wave, so its purpose is unconfirmed. Earlier stages, recorded by Sansec Watch, the firm’s content security policy monitoring service, point to crypto-themed lures.

On 12 December 2025, a customer logged in to an infected store received a script from manulfie.click. It loaded a page on crypto-insider.top and, five minutes later, one on leqdger.click, a misspelling of the crypto wallet brand Ledger.

On 15 and 16 December, neswnsssn.click served the same leqdger.click script on two more stores. The look-alike domain was registered on 12 September 2025 and has since expired.

Where does the malicious code live in Magento?

It lives in the database, in the cms_block table, not in your theme. Across the campaign, eComscan found the loader in cms_block on 148 server installs and never in core_config_data or theme files. An owner who diffs the theme against a clean copy, or checks the HTML head settings in admin, will find nothing.

For the attacker, this is an efficient hiding place. A CMS block is a reusable content fragment that layouts render across storefront pages, so a single database row can reach a large share of the store’s shoppers. Sansec advises searching the cms_page table as well.

What is fpCode, and why does the payload keep running?

fpCode is a key in the shopper’s browser storage that holds attacker code between visits. The first of the two October scripts reads it. If a value is present, the script puts the stored code in an invisible div and clicks it, and the browser runs that code as an event handler.

No eval() call appears, which can help the code slip past filters that look for that function. Nothing in the CMS block writes fpCode, so the remote script from deepveindrilling.com must set it.

That changes the cleanup. A shopper who received the payload once re-runs it on every later page view, even if deepveindrilling.com is offline or blocked. The March 2026 version deleted its stored payload after one run; this one keeps it. Nobody can easily count how many browsers still hold it, because that state never reaches the server.

How did the attackers get into these Magento stores?

The October activity did not depend on a new bug. It rode on access the group already had, which appears to have come through Magento file-upload flaws. Some infected stores had files uploaded through PolyShell (CVE-2026-48356) or SessionReaper (CVE-2025-54236).

In March 2026, the group injected code into 471 stores in one hour by uploading webshells through PolyShell. That is nearly half the campaign’s total in sixty minutes.

Two stores from Sansec’s research show both sides of the problem. The first ran Magento 2.4.7-p1 and held PolyShell webshells disguised as PNG images, next to a malicious CMS block that switched from additionalver.com to deepveindrilling.com on 7 October. It had not installed Adobe’s PolyShell fix, APSB26-73.

The second ran Magento 2.4.7-p10 with no missing core patches and was still infected on 23 October. Earlier scans had found a rogue admin account and a GSocket backdoor, a tool that keeps a remote shell open for the attacker.

Patching closed the bugs Adobe listed in its bulletins. It did nothing about the admin user and backdoor already inside, and it never removes webshells, cron jobs, altered CMS content or stolen credentials. Our hack-recovery cases show what that kind of eviction involves in practice.

Sansec’s position is blunt: if your store loads any domain from its indicator list, the attacker can write to your database, and deleting the script does not remove that access. For how shops end up on target lists, see our breakdown of how hackers find and target vulnerable websites.

Which older domains are still a risk?

Search for every campaign domain, not only the newest. The current one still serves code, and two expired ones now belong to someone else. Sansec tracked five loader domains over 15 months, and store counts overlap as the operator rotated infrastructure:

Two more domains turned up on a small number of stores: hdfdsi84j3h.top, registered three minutes after lanhd6549tdhse.top, and c85grt98sd.com. Sansec Watch logged visitors’ browsers connecting to all four earlier loader domains. additionalver.com alone accounted for around 52,000 reports.

The two re-registered names now use the nameservers of abovedomains.com, a domain-parking service. Between August and October 2026, Sansec still found the manulfie.click loader on nine stores and the neswnsssn.click loader on six.

Browsers on those shops send the previous page and the current page title to the domain’s new owner. Those browsers also execute whatever script the new owner serves. Whoever holds a parked domain gets a ready-made foothold in those storefronts. Sansec publishes the full indicator list at the end of its report; check your store against every entry.

How do I check and clean my Magento store, step by step?

Preserve evidence first, then search the database, then evict the attacker, in that order. This is the sequence we use on Magento recovery jobs, and it follows Sansec’s guidance.

1. Preserve. Take a full database dump, a copy of the web root and the access logs before changing anything. The update timestamp on a malicious CMS block shows when the attacker last wrote to it.
2. Search the CMS tables. Run read-only searches on the content column of cms_block and cms_page for fpCode, se_referrer, every domain in the table above and base64-encoded strings inside script tags. A query such as SELECT block_id, identifier FROM cms_block WHERE content LIKE ‘%fpCode%’ is a good start.
3. Hunt webshells. Inspect upload and media directories for executable files, including “images” that contain PHP.
4. Audit admins and processes. Remove unknown admin accounts and review API integrations. Look for unfamiliar long-running processes, such as a GSocket backdoor, and for new cron entries.
5. Patch. Install APSB26-73 (PolyShell) and APSB25-88 (SessionReaper). Sansec says its Shield product blocks both attacks while you schedule the upgrade. A website firewall in front of the store can also filter exploit requests aimed at upload endpoints.
6. Rotate credentials. Change database, admin and API integration passwords from a trusted machine, and only after the backdoors are gone. Rotating while a shell is live hands the attacker the new passwords.
7. Clean and re-check. Remove the malicious blocks, then search the tables again 24 to 48 hours later. This operator rewrites blocks. To flush stored payloads from returning shoppers, consider serving a Clear-Site-Data header with the storage directive for a while after cleanup.

Practitioner’s note: test the store with several clean browser profiles, including a logged-in shopper session with realistic desktop settings. Compare the rendered page and its network requests, not the HTTP status.

Then open the store in a browser profile that visited during the infection. If fpCode is still in that profile’s site storage, clear it and confirm nothing runs.

Common mistake: declaring a store clean after one scanner run. That run may be exactly the visitor the operator chose to serve nothing.

Ongoing content and file checks, such as our website antivirus monitoring, help catch the next CMS rewrite on the day it happens.

FAQ

How do I check if my Magento store is infected by this campaign?

Search the content of the cms_block and cms_page tables for fpCode, se_referrer and every domain on Sansec's indicator list, including deepveindrilling.com, additionalver.com and manulfie.click. Theme-file checks and a single URL scan will miss it, because the code sits in the database and hides from automated browsers.

Why did a security scan show my store as clean?

The loader fingerprints each visitor and looks for automation markers such as navigator.webdriver and ChromeDriver's cdc_ properties. Automated scanners get an ordinary page. On one infected store, urlscan.io received HTTP 200 and no added content.

Is a fully patched Magento 2.4.7 store safe?

Not if the attacker got in before you patched. Sansec found a Magento 2.4.7-p10 store with no missing core patches that was still infected on 23 October 2026, because a rogue admin account and a GSocket backdoor were never removed.

Does deleting the script from the CMS block fix the problem?

No. Sansec says any store that loads a campaign domain should assume the attacker can write to its database. Remove webshells and unknown admins, install APSB26-73 and APSB25-88, and rotate database, admin and API integration passwords.

Are expired domains like manulfie.click still dangerous?

They can be. manulfie.click and neswnsssn.click were re-registered in May 2026 and now sit on a parking service. Stores that still reference them send page data to the new owner and will run any script that owner decides to serve.

If your search turns up fpCode or one of these domains, the job is evicting the attacker, not deleting a line of code. Our malware removal and website protection team handles Magento recovery from evidence capture to firewall hardening.