Magento Security Alert: Malicious CMS Block Loader Targets Hundreds of E-commerce Stores

A persistent malware campaign is targeting Magento and Adobe Commerce stores by injecting malicious JavaScript into CMS blocks.

A new report from Sansec, published on October 24, 2026, reveals that attackers are using deepveindrilling.com as part of an ongoing campaign targeting e-commerce websites. The investigation found the latest loader on 83 stores, while the broader campaign has affected hundreds of stores over multiple waves since July 2025.

The attack highlights a critical security lesson for Magento store owners: removing malicious JavaScript alone may not be enough to secure a compromised store.

What Is the Magento CMS Block Loader Attack?

Magento and Adobe Commerce use CMS blocks to manage reusable storefront content, including headers, footers, banners, and promotional sections.

Attackers have abused this functionality to inject JavaScript into the database. When a shopper visits an affected storefront, the injected script communicates with attacker-controlled infrastructure to determine whether to deliver additional malicious content.

The latest campaign uses the domain deepveindrilling.com, which Sansec identified in infected CMS blocks.

According to the investigation, the broader campaign has used multiple domains over approximately 15 months, changing its infrastructure to continue operating.

How Does the Attack Work?

The campaign uses several techniques to make detection and removal more difficult.

1. Malicious JavaScript in CMS Blocks

The attacker injects JavaScript into the cms_block database table. Because CMS blocks can appear across multiple storefront pages, a compromised block may expose a large portion of the customer journey to malicious scripts.

2. Browser Fingerprinting

The latest loader collects browser characteristics, including automation indicators and device-related information. The remote server can use these signals to distinguish real shoppers from automated security scanners.

This selective behavior can make routine security scans appear clean even when the storefront is compromised.

3. Persistent Browser-Side Payloads

The loader can store code in the visitor’s browser using localStorage and execute the stored payload on subsequent page views.

Consequently, blocking the remote domain or removing its script from a CMS block may not neutralize every previously delivered payload.

4. Continued Access Through Backdoors

Sansec also reported compromised stores with rogue administrator accounts, backdoors, or other persistence mechanisms.

This is why an infected CMS block should be treated as a potential indicator of a deeper compromise—not simply a frontend content issue.

How to Check Your Magento or Adobe Commerce Store

Store administrators and development teams should investigate both the database and the filesystem.

Step 1: Search CMS Blocks

Run the following read-only SQL query against your Magento database:

SELECT block_id, identifier, update_time
FROM cms_block
WHERE content LIKE '%fpCode%'
   OR content LIKE '%se_referrer%'
   OR content LIKE '%localStorage.getItem%';

If your database uses a table prefix, replace cms_block with the appropriate prefixed table name.

Step 2: Search CMS Pages

Repeat the same investigation against cms_page:

SELECT page_id, identifier, update_time
FROM cms_page
WHERE content LIKE '%fpCode%'
   OR content LIKE '%se_referrer%'
   OR content LIKE '%localStorage.getItem%';

These searches can identify suspicious patterns associated with the campaign. However, a clean result does not prove that the store is uncompromised: attackers may obfuscate indicators or use different code.

Step 3: Check for Suspicious Files

Review unexpected files in upload and media directories, including:

find pub/media/custom_options/ pub/media/customer_address/ \
  -type f ! -name '.htaccess'

find . -name 'accesson.php' -type f

Investigate unfamiliar executable files, unexpected PHP files in writable directories, and suspicious file timestamps.

Do not automatically delete every matching file. Verify each finding against your application, installed extensions, deployment history, and legitimate customizations.

Step 4: Review Administrator Accounts and Database Changes

Check for:

• Unknown administrator accounts and unexpected role changes.
• CMS blocks or pages modified without an approved deployment.
• Suspicious database changes and unexpected scheduled tasks.
• Unfamiliar PHP processes, backdoors, and unauthorized file uploads.
• Unexpected third-party JavaScript requests from storefront pages.

Review access logs and administrative audit records, where available, to help determine the initial entry point and scope of the compromise.

What Should You Do If Your Store Is Infected?

If you find a suspicious loader, follow an incident-response process rather than treating the issue as a simple script removal.

1. Preserve evidence: Save relevant database records, logs, suspicious files, and timestamps before making changes.
2. Contain the threat: Restrict unauthorized access and block confirmed malicious destinations through appropriate security controls.
3. Remove the injected code: Clean affected CMS blocks and pages after preserving evidence.
4. Investigate persistence: Check for backdoors, rogue administrator accounts, modified application files, and other unauthorized access mechanisms.
5. Patch the entry point: Verify your exact Magento or Adobe Commerce version and apply the applicable security fixes.
6. Rotate credentials: Once unauthorized access has been contained, rotate affected administrator, database, API integration, and other potentially exposed credentials.
7. Validate the cleanup: Scan the application and database, review network requests, and test critical storefront and checkout flows.

Important: A domain block is a containment measure, not a complete remediation strategy. If an attacker retains database-write access or another backdoor, malicious code can return.

Why Keeping Magento Patched Is Not Enough

Sansec’s investigation also found that previously patched stores could still receive the malicious loader when attackers retained another route into the environment.

This demonstrates the difference between vulnerability management and incident response.

Keeping Magento core and extensions updated is essential, but it cannot remove an existing backdoor or automatically reverse unauthorized database changes.

A robust security program should combine:

• Timely Adobe security patching.
• Regular application and database malware scans.
• Monitoring of CMS content changes.
• Strong administrator authentication and least-privilege access.
• File integrity monitoring and restricted write permissions.
• Web application firewall protection.
• Centralized logging and ongoing security reviews.

Final Thoughts

The deepveindrilling.com campaign is another reminder that Magento security extends beyond core code and server configuration. CMS blocks, database content, uploaded files, administrator accounts, and third-party scripts can all become part of an attacker’s persistence strategy.

If you operate a Magento or Adobe Commerce store, review CMS content for unexpected scripts, investigate suspicious filesystem changes, and confirm that the environment is free of unauthorized access.

The goal is not just to remove the visible malware. It is to identify the initial compromise, eliminate persistence, and prevent the attacker from returning.

Source

Sansec — deepveindrilling.com: Magento CMS block loader hits 953 stores

This article is an independent technical summary based on publicly reported security research. Validate findings against your own environment before taking remediation actions.