Scanner-Evading Magento Loader Campaign Infects 953 Online Stores

A long-running campaign has quietly planted malicious JavaScript in 953 online stores since July 2025, most of them running Magento, and its newest infrastructure is built to show nothing at all to security scanners. Dutch e-commerce security firm Sansec published its findings on October 24, 2026, tying the activity to the same operator behind the PolyShell mass attack on Magento stores earlier this year.

The latest loader domain, deepveindrilling[.]com, was registered on October 6, 2026. According to Sansec, the first stores began loading it the next evening, and it has since turned up in the content blocks of 83 stores. Most of those are repeat victims: 60 of the 83 already ran one of the operator’s earlier loaders, and 34 had been infected since October 2025.

Hiding inside Magento CMS blocks

Instead of editing theme files or configuration, the operator stores the loader in Magento’s cms_block database table, which holds the static content blocks a store renders into its pages. Sansec said its scanner found the code there on 148 server installs over the course of the campaign, and never in core_config_data or theme files. That choice keeps the code out of places many file integrity checks watch.

When a shopper loads an infected page, the injected code asks the attacker’s server what to do next. Sansec documented 2 loader versions in October:

• The October 7 version pulled a script from the attacker’s domain and replayed a payload cached in the browser’s localStorage under the key fpCode. That means a visitor who received the payload once keeps running it on later visits, even if the domain goes offline or gets blocked.
• The October 23 version added a browser fingerprint. It flags automated browsers through signals such as navigator.webdriver, Selenium globals and ChromeDriver properties, and also collects GPU name, CPU cores, memory, screen size, time zone and language data.

The server picks its response from that fingerprint. When an automated Chrome browser on a public scanning service loaded an infected store, it received a normal page with no added content. Sansec said it has not yet captured the final payload served to real shoppers.

Five domains and a Ledger lookalike

The operator has rotated through 5 main loader domains in 15 months, moving to a new address every few months. Sansec’s store counts for each:

• manulfie[.]click: first seen July 9, 2025, on 863 stores
• neswnsssn[.]click: first seen December 12, 2025, on 494 stores
• lanhd6549tdhse[.]top: first seen March 30, 2026, on 355 stores
• additionalver[.]com: first seen June 8, 2026, on 246 stores
• deepveindrilling[.]com: first seen October 7, 2026, on 83 stores

Earlier waves routed visitors through Keitaro, a commercial ad tracker that also works as a traffic distribution system, deciding per visitor whether to return a payload, a redirect or nothing. Sansec said its monitoring caught one of those payloads in December 2025, when a logged-in customer of an infected store received scripts from crypto-insider[.]top and leqdger[.]click, a misspelling of crypto wallet brand Ledger. The newest domain drops Keitaro and builds the bot filtering into the loader itself.

Two older domains expired and were re-registered in May 2026 and now sit on a parking service. Sansec warned that stores still loading them send visitor data to whoever owns those domains now, and visitors’ browsers run any script those domains return.

PolyShell and SessionReaper opened the door

Sansec ties the earlier waves to Magento file upload flaws. On March 30, 2026, the operator injected the loader into 471 stores in a single hour after uploading webshells through PolyShell, tracked as CVE-2026-48356. Adobe rates it Critical with a CVSS score of 9.6 and fixed it for supported release lines in security bulletin APSB26-73, published July 14, 2026. As of its latest revision, that bulletin still states Adobe is not aware of exploits in the wild for the issues it addresses.

Across the campaign, Sansec found the loader on 169 Magento 2 installs missing at least 1 core patch. Of those, 102 (60%) also had files uploaded through PolyShell or SessionReaper, CVE-2025-54236, an improper input validation flaw Adobe patched in APSB25-88 and has acknowledged as exploited in the wild.

Patching alone did not save every store. Sansec described a fully patched store on Magento 2.4.7-p10 that received the newest loader on October 23, 1 hour after a clean scan. The researchers had found a rogue admin account on that store in September and a GSocket backdoor days later, showing the operator kept access long after the original entry point.

Why removing the script is not enough

Sansec stressed that any store loading one of the campaign domains should assume the attacker can write to its database. Deleting the injected block does not remove that access. The firm recommends that merchants:

• Search the cms_block and cms_page tables for the loader patterns fpCode, se_referrer and localStorage.getItem
• Look for uploaded files in Magento’s custom options and customer address media folders, and for the accesson.php backdoor
• Review admin accounts for users they do not recognize and check for unfamiliar processes
• Rotate database, admin and API integration passwords after cleanup
• Install APSB26-73 for PolyShell and APSB25-88 for SessionReaper

The campaign lands during a rough stretch for PHP-based commerce platforms, which are also facing exploitation attempts tied to the PHP2Shell vulnerabilities. Adobe had not issued any public statement about this campaign at time of publication.