Magento Sites Compromised by JavaScript Malware Campaign

An unknown threat actor has infected 953 online stores — most running Magento — in a campaign that has been active since July 2025, according to Dutch e-commerce security company Sansec.

Scope, timeline, and the five loader domains

Sansec mapped the campaign to five distinct JavaScript loader domains that appeared in stages over more than a year: manulfie[.]click (first seen July 2025); neswnsssn[.]click (first seen December 2025); lanhd6549tdhse[.]top (first seen March 2026); additionalver[.]com (first seen June 2026); and deepveindrilling[.]com (first seen October 2026). The researcher team reported finding deepveindrilling[.]com in the CMS blocks of 83 online stores since that domain was registered on October 6, 2026.

How the loader avoids scanners and targets real shoppers

Sansec described a lightweight insertion — a small piece of code added to store pages via Magento CMS blocks — that causes a visiting browser to contact the attacker's server for instructions. "When you visit, that code makes your browser ask the group's server what to do next," Sansec said. "The server first checks whether you are a real shopper or a security scanner, so scanners get nothing."

The most recent loader domain is hosted behind Cloudflare and only responds to script requests from real visitors of infected stores. The loader itself is staged within Magento's cms_block database table, which is used to render static content into storefront pages. Sansec said the attacker may either modify an existing CMS block (such as header, footer, or promotional banner) or create a new block to run the loader.

Two loader behaviors: persistence and fingerprinting

Sansec observed two distinct versions of the external JavaScript loader. In one version, the JavaScript fetched from the attacker's domain stores a payload in the browser's localStorage; that stashed code is executed again on subsequent visits, meaning the infection can persist even if the external domain later becomes unavailable.

The second version builds on persistence with browser fingerprinting to filter out bots and security scanners and ensure only "real shoppers" are exposed to the malicious code. Early campaign iterations also used Keitaro, an advertising tracker and analytics platform, as a traffic distribution system (TDS) to route visitors to different responses — delivering a payload, performing a redirect, or returning nothing — based on visitor characteristics.

Initial access: PolyShell (CVE-2026-48356), SessionReaper (CVE-2025-54236), and account compromise

Sansec estimates that 471 Magento stores were injected with the loader through the PolyShell vulnerability, tracked as CVE-2026-48356. Another 102 stores saw files uploaded through PolyShell or SessionReaper (CVE-2025-54236). In one case Sansec described, "One store on Magento 2.4.7-p1 had PolyShell webshells disguised as PNG images in pub/media/custom_options/quote/, next to the additionalver.com loader in a CMS block." Sansec noted that the affected store "still lacks APSB26-73, Adobe's PolyShell fix for supported release lines."

Sansec also documented a separate incident on a Magento 2.4.7-p10 site with no missing core patches, where attackers added a rogue administrator account and used it to inject the malicious code — a reminder that missing patches are not the only route to compromise.

Observed responses from additionalver[.]com and deepveindrilling[.]com

Sansec recorded behavioral differences between the earlier additionalver[.]com and the later deepveindrilling[.]com deployments. Requesting the additionalver[.]com script as a Windows desktop visitor returned the response "QWE=123;," which Sansec said does nothing apart from setting a cookie that marks the visitor for 24 hours. Deepveindrilling[.]com, by contrast, drops the Keitaro component and folds the bot-filtering logic into the loader itself.

What this means for Magento site owners, security teams, and shoppers

• Magento site owners and administrators: Sansec advises auditing sites for suspicious administrator accounts and unexpected CMS blocks in the cms_block and cms_page tables, keeping installations up-to-date, and enforcing strong passwords. The report’s examples include stores missing the APSB26-73 PolyShell fix and a store that was compromised despite having current core patches.
• Security teams and incident responders: Because the loader evades scanners and can persist in a visitor’s browser via localStorage, teams should look beyond immediate network indicators and inspect CMS content and local storage behavior on client systems to detect lingering payloads.
• Shoppers and end users: The attacker’s server performs checks to return payloads only to real visitors, meaning normal browsing can expose shoppers to unknown final payloads; Sansec said the exact nature of the final payload remains unknown.

The disclosure comes amid broad attention to PHP2Shell, a pair of critical PHP vulnerabilities (CVE-2026-109618 and CVE-2026-109619) that have seen exploitation attempts since their disclosure last week. Perplexity researcher Adel Karimi recorded what appears to be the first in-the-wild successful use of those vulnerabilities to run shell commands on honeypot servers; those commands used wget, curl, or PHP CLI to fetch additional payloads from "162.35.99[.]94:80," though no downloaded second-stage artifacts have been observed so far.

The campaign described by Sansec demonstrates a persistent, adaptive approach: small injections into CMS blocks that call out to staged loaders, evasion of automated scanners, use of tracking/TDS platforms in early phases, and later integration of bot filters directly into the loader. For now, the exact final payloads remain unspecified, but the infection vector and countermeasures are clear — inspect CMS content, close known vulnerability paths, and check for rogue administrator accounts and persistent client-side artifacts.

Original report: https://thehackernews.com/2026/10/hackers-infect-953-online-stores-with.html