953 Magento Stores Infected: When Patching Doesn't Stop Persistent Malware

A malware campaign active since July 2025 has infected 953 online stores, primarily Magento platforms, with JavaScript loaders that evade detection through browser fingerprinting. The disturbing part isn't the count—it's the mechanism: a store running Magento 2.4.7-p10, with no missing patches, was reinfected within an hour, proving that software updates don't necessarily erase a compromise.

Editor's note: this article is based on a single primary report from Sansec, cited by SecurityWeek, without independent replication of the technical data. The mechanisms described reflect the original source's observations.

The Infection Chain: From Known Vulnerabilities to Evasive Fingerprinting

According to the Sansec report cited by SecurityWeek, the threat actor exploited two critical vulnerabilities for initial access: CVE-2026-48356 (PolyShell) and CVE-2025-54236 (SessionReaper). In March 2026, 471 stores were compromised via PolyShell, while over 100 had files uploaded through one of the two vectors.

The campaign's distinguishing feature is a JavaScript loader that adapts its behavior to the visitor. The code performs browser fingerprinting and serves the payload only to sessions exhibiting characteristics of real users, returning empty responses to security scanners and analysis bots. This mechanism evades static detection of indicators of compromise.

The command-and-control infrastructure has rotated through five domains: manulfie.click, neswnsssn.click, lanhd6549tdhse.top, additionalver.com, and, as of this month, deepveindrilling.com. The first two expired and were re-registered in May 2026 with abovedomains.com nameservers, a parking service. Despite this, between August and October 2026 Sansec still detected manulfie.click active on 9 stores and neswnsssn.click on 6, evidence that compromised installations were not cleaned.

The shift to deepveindrilling.com represents a significant evolution. The domain sits behind Cloudflare. According to Sansec, it responds selectively: only requests originating from scripts loaded in the browsers of infected stores' visitors receive the actual payload. Client-side fingerprinting in the browser and selective server-side response are distinct mechanisms operating in sequence, not a unified architecture. This configuration renders static IOC-based blocking ineffective and complicates researcher analysis. The loader was found on 83 stores, 60 of which hosted previous versions of the malicious code, indicating repeated reinfections.

"Patched stores get the loader too. One store on Magento 2.4.7-p10, with no missing core patches, got deepveindrilling.com at 16:46 UTC on October 23, one hour after a clean scan." — Sansec, reported by SecurityWeek

The 2.4.7-p10 Store Case: Why Patching Isn't Enough

The most significant episode for understanding the threat involves a store on Magento 2.4.7-p10, a version with no missing patches. At 16:46 UTC on October 23, 2026, one hour after a clean scan, the system was infected with the deepveindrilling.com loader. The timeline rules out a software vulnerability as the vector.

Traces of persistence had been available for weeks: eComscan, Sansec's monitoring service, had identified a rogue admin account on September 16 and a GSocket backdoor on September 24. The source does not provide technical details on GSocket's specific operation in the documented case. Its presence indicates the actor had consolidated server-side control independent of the application code's state.

The mechanism rendered the entire patch-management cycle ineffective. The store was formally up to date, with no open CVEs and a negative scan. The backdoor nullified that operational state.

Infrastructure Evolution and the Ghost Domain Problem

The campaign's domain management reveals an unusual longevity strategy for the e-commerce sector. The four initial domains accumulated significant signals: Sansec Watch, the company's CSP monitoring service, collected approximately 52,000 load reports for additionalver.com from visitors' browsers. The data does not specify whether these are total requests or unique visitors, and the source does not quantify the number of stores actually exposed to the final payload.

Expired domains constitute an infrastructure maintenance problem for merchants. Re-registration to abovedomains.com moved them to a parking service, but the malicious code remaining on stores continues to attempt loading. This generates visible failures in logs, but also a risk of reintroduction if a new domain buyer restores the original functionality. The situation is complicated because expired domains can evade active monitoring based on IOC lists, which prioritize currently resolvable indicators.

The transition to deepveindrilling.com added another layer of selectivity. The combination of Cloudflare as a proxy and conditional response logic tied to the visitor's context makes any binary classification of the domain as "malicious" or "legitimate" problematic. The response depends on who asks, when, and from where.

Why This Matters

The case documented by Sansec raises questions about the prevailing e-commerce security model. Patch-based compliance—keeping software updated—remains necessary but insufficient when the threat actor has already established persistence. The 2.4.7-p10 store was formally protected against known vulnerabilities; it was not protected against an access already conquered.

The campaign also shows how detection evasion has become central to threat operations. Visitor fingerprinting and selective server-side response are not new techniques, but their combination in a long-running campaign indicates an investment in discovery-resistant access operations. Sansec has not yet captured the final payload of the current version, leaving the specific objective open: previous loader versions served cryptocurrency-themed scripts, including one imitating the Ledger brand.

The persistence of expired domains on infected stores adds a temporal dimension to the problem. The failure to clean is not just a technical error; it creates a bridge to future reuse of the same indicators. Merchants who do not actively remove the loader code remain exposed even when the original infrastructure changes ownership or function.

What to Do Now

For merchants operating on Magento, the case suggests three context-specific priorities. First: verify the presence of unauthorized administrative accounts, since the rogue account from September 16 preceded the October 23 reinfection by weeks. Second: actively remove the loader code even from stores where command-and-control domains appear inactive or expired, since 9 stores still hosted manulfie.click and 6 still hosted neswnsssn.click months after expiration. Third: supplement CSP monitoring with analysis of the actual behavior of loaded code, not just blocked-domain lists, because deepveindrilling.com evades static classification.

For security vendors, the case indicates that patch-compliance verification must be accompanied by persistence checks. A clean scan does not guarantee absence of compromise if the actor has already established alternative access.

Editor's Closing

The 953-store campaign isn't a case of a zero-day vulnerability that slipped past the vendor. It's a case of persistence that made the patch irrelevant. The number that stays with you is the hour: sixty minutes between a clean scan and reinfection, with weeks of warning ignored. The actor's technique is evasive, but the point of failure is operational.

Sources

• securityweek.com
• radar.offseq.com
• techbytes.app
• coesecurity.com