The Magento malware campaign compromised 953 online stores between July 2025 and October 2026, according to Sansec’s October 24, 2026 investigation. The injected JavaScript fingerprints visitors and can withhold its payload from automated scanners, so a clean crawl doesn’t prove a store is safe. Merchants should audit CMS database content, administrator access, API integrations, server persistence and shoppers’ browser storage.
A CMS-block loader is malicious code inserted into database-managed page content so that a storefront loads attacker-controlled JavaScript. In this campaign, deleting the visible script isn’t enough: retained server access and code saved in browser localStorage can survive superficial cleanup.
What is the Magento malware campaign doing?
The Magento malware campaign places a JavaScript loader in Magento or Adobe Commerce CMS content, profiles each visitor’s browser and selectively serves follow-on code. Sansec reported on October 24, 2026 that the operation had compromised 953 stores since July 2025 and was associated with five principal loader domains.
Sansec found the loader in the cms_block.content database field. Its scanner identified that location on 148 server installations in 2026, while finding no campaign loader in core_config_data or theme files. Merchants shouldn’t limit a search to templates simply because many older Magecart investigations started there.
The newest observed domain, deepveindrilling.com, was registered on October 6, 2026. Stores began loading it on October 7, with Sansec recording the first detection at 21:54 UTC. By October 8, Sansec’s crawler had identified the initial two-script version on 74 stores; the domain was ultimately observed in CMS blocks on 83 stores.
The scale also grew in bursts. Sansec reported that lanhd6549tdhse.top was injected into 471 stores within one hour on March 30, 2026, following PolyShell webshell uploads. That single-source finding represents about 49.4% of the 953-store campaign total: 471 divided by 953, multiplied by 100.
How does the malware hide from security scanners?
The Magento malware campaign evades scanners by collecting automation signals, WebGL and GPU data, CPU core counts, memory, screen dimensions, time zone, languages and browser client hints. On October 24, 2026, Sansec’s automated Chrome session received an HTTP 200 response but no injected content, demonstrating selective delivery.
On October 23, 2026, the operator replaced the earlier external script tag with an inline fingerprinting loader. Nine additional stores received the loader that day, and previously infected CMS blocks were rewritten. When Sansec re-crawled 71 stores on October 24, every one served the revised version.
A successful HTTP response can therefore be misleading. Status monitoring may confirm that a remote domain answered, while never seeing the code shown to an accepted shopper. In my view, treating a clean headless-browser scan as proof of remediation is the most dangerous shortcut in this incident.
Sansec had not captured the final payload delivered to a visitor accepted by the newest loader as of October 24, 2026. The campaign’s ultimate action therefore remained unverified at publication. Calling the unseen payload a confirmed payment skimmer, credential stealer or redirector would go beyond the available evidence.
Why can the infection survive after the domain is blocked?
The Magento malware campaign can persist in shoppers’ browsers because an October 2026 loader read executable code from localStorage.fpCode. Code retained in browser storage can run on later page views after the loader domain is blocked or unavailable, so removing the server-side injection does not erase copies already stored on customer devices.
The October 7, 2026 version placed the stored code into an invisible element’s onclick handler and executed it without using eval(). A scanner that searches only for conspicuous calls to eval() could miss the behavior. Blocking the domain at DNS or Content Security Policy level stops one delivery path, not an already cached instruction set.
Adobe Commerce Content Security Policy can still provide valuable warning signals. Adobe’s 2026 documentation says Adobe Commerce 2.4.7 and later uses restrict mode by default on payment pages and report-only mode elsewhere. Sansec reported receiving approximately 52,000 CSP reports involving the earlier campaign domain additionalver.com in 2026.
Those reports can expose unexpected third-party connections even when a crawler receives nothing. Merchants should preserve CSP telemetry before making changes, then compare affected URLs, timestamps and user agents with CMS update records.
How should Magento merchants investigate and clean up?
Magento and Adobe Commerce merchants should preserve evidence, search CMS database fields, identify unauthorized access and remove every persistence mechanism before rotating credentials. Sansec’s 2026 guidance says deleting the injected JavaScript alone does not eliminate database access, rogue administrator accounts, API integrations, webshells or backdoors left by the operator.
The following response sequence covers the campaign-specific evidence that merchants should examine in 2026:
- Search
cms_block.contentandcms_page.contentforfpCode,se_referrerandlocalStorage.getItem. Include database tables with custom prefixes, and preserve matching rows before editing them. - Use each CMS record’s
update_timevalue to reconstruct unauthorized changes. Correlate those times with administrator logins, deployment activity, API calls and server logs. - Inspect
admin_userfor unknown or unexpectedly reactivated accounts. Review API integrations and unfamiliar processes rather than assuming the database injection was the attacker’s only foothold. - Hunt for
accesson.php, GSocket and executable or disguised files underpub/media/custom_options/andpub/media/customer_address/. - Apply relevant Adobe security updates, complete forensic cleanup, and then rotate database, administrator and API-integration credentials. Rotation before removing persistence may hand fresh credentials back to the attacker.
Patch status deserves nuance. Sansec reported in 2026 that 169 affected Magento 2 installations were missing at least one core patch; 102 of those stores, or 60%, also held files associated with PolyShell or SessionReaper. Yet a Magento 2.4.7-p10 store with no missing core patches received the new loader on October 23, 2026 after a rogue administrator was detected on September 16 and a GSocket backdoor on September 24.
That edge case matters. Fully patched software can be reinfected when an older compromise leaves valid access or server persistence behind. Honestly, patching without investigating accounts and filesystem artifacts only makes sense as temporary containment, not as a completed response.
Which vulnerabilities and campaigns are related?
The Magento malware campaign has observed links to older PolyShell and SessionReaper compromise artifacts, but it is separate from StyleSmuggler. Adobe published the PolyShell-related APSB26-73 update on July 14, 2026, while SessionReaper is CVE-2025-54236, a CVSS 9.1 vulnerability addressed by APSB25-88 on September 9, 2025.
| Event | Date | Relationship to this campaign | Merchant action |
|---|---|---|---|
| SessionReaper, CVE-2025-54236 | September 9, 2025 advisory | Associated files appeared on some affected stores in Sansec’s 2026 sample | Verify APSB25-88 coverage and investigate past access |
| PolyShell, CVE-2026-48356 | July 14, 2026 update | Webshell artifacts and a rapid loader injection were reported by Sansec in 2026 | Install APSB26-73 and hunt for persistence |
| StyleSmuggler, CVE-2026-75650 | September 7, 2026 hotfix | Separate unauthenticated remote-code-execution chain | Apply its hotfix, but do not label it as the origin of the CMS-block campaign |
| Fingerprinting loader rewrite | October 23, 2026 | Campaign operator added selective browser-based delivery | Use database, access and CSP evidence rather than crawler results alone |
Adobe later confirmed exploitation in the wild for SessionReaper, according to its APSB25-88 security bulletin. Sansec recommends installing APSB26-73 while investigating the newer campaign, but neither update removes malicious accounts, altered CMS records or backdoors created before patching.
StyleSmuggler’s first confirmed exploitation occurred on September 4, 2026, and Adobe released its hotfix three days later. Our separate analysis of the Magento StyleSmuggler zero-day explains that exploit chain. Mixing the incidents can send responders toward the wrong indicators and produce an inaccurate breach timeline.
Magento malware campaign FAQ
Can a clean Magento scan prove the store is safe?
No. The Magento malware campaign withheld injected content from Sansec’s automated Chrome on October 24, 2026, despite returning HTTP 200, so database inspection, account review and server forensics are needed alongside browser scanning.
Where should merchants search for the malicious code?
Merchants should search cms_block.content and cms_page.content for fpCode, se_referrer and localStorage.getItem, including prefixed database tables. Sansec identified the campaign loader in cms_block.content on 148 server installations in 2026.
Does blocking deepveindrilling.com remove the infection?
No. Blocking deepveindrilling.com can stop that network path, but code saved in browser localStorage can execute on later visits, and the store may retain rogue accounts, database access or server backdoors.
Was StyleSmuggler responsible for the 953 compromised stores?
No. StyleSmuggler, tracked as CVE-2026-75650, is a separate September 2026 exploit chain. The 953-store operation documented by Sansec on October 24, 2026 centers on recurring CMS-database loader injection, selective delivery and retained access.