Magento Malware Campaign Hits 953 Online Stores: How to Detect the Infection and Remove Hidden Backdoors

A major malware campaign has exposed a dangerous weakness in online store security: removing malicious code or installing the latest software updates does not necessarily mean a compromised store is safe again.

According to research published by e-commerce security company Sansec on October 24, 2026, a criminal operation has compromised 953 online stores since July 2025, predominantly websites running Magento and Adobe Commerce. The attackers have repeatedly changed their malicious infrastructure while maintaining access to stores infected months earlier.

The latest stage of the campaign involves a domain called deepveindrilling.com, which researchers identified in the content management system of 83 online stores. Of those, 60 had already been affected by earlier versions of the same campaign.

The most concerning finding is that some previously compromised stores remained vulnerable even after their Magento software had been updated. The attackers could continue modifying website content through unauthorized accounts, malicious files or other persistent access mechanisms.

The essential security lesson is clear: an infected online store requires a complete investigation and removal of the attacker's access, not simply a malware scan or software update.

What Happened in the Magento Malware Campaign?

The campaign uncovered by Sansec uses a technique that places malicious JavaScript loaders inside Magento CMS blocks. These blocks normally contain legitimate website elements such as promotional messages, product information, banners and other reusable content.

Instead of placing all malicious functionality directly into the storefront, attackers insert a relatively small script that contacts an external server. That server can decide what additional code should be delivered to the visitor.

This approach makes the infection harder to identify because the website may look completely normal to customers, administrators and automated security scanners.

The October 2026 investigation established several important facts:

• The operation has affected 953 online stores since July 2025.
• The newest malicious domain, deepveindrilling.com, was detected on 83 stores.
• 60 of those 83 stores had previously contained an earlier malicious loader.
• Some stores had been carrying elements of the campaign since October 2025.
• The malicious code was primarily embedded in Magento CMS blocks stored in the database.
• The attackers used browser fingerprinting to distinguish ordinary shoppers from automated security tools.
• Earlier infection waves were associated with vulnerabilities known as PolyShell and SessionReaper.
• At least one fully patched Magento installation was subsequently reinfected through access mechanisms that had already been established.

These numbers refer to stores identified across the campaign, not 953 simultaneous infections or 953 confirmed thefts of payment information. Sansec had not captured the final payload delivered by the newest loader when its October 24 investigation was published.

However, allowing criminals to control JavaScript delivered to shoppers creates a serious risk of unauthorized redirects, fraudulent content, credential theft and payment-data interception.

The original investigation, including the technical indicators of compromise, is available in Sansec's research into the Magento CMS block malware campaign.

How the Malware Works Inside an Online Store

The attack combines several techniques designed to maintain access, conceal malicious activity and make detection less reliable.

1. Attackers Gain Access to the Store

The initial intrusion may occur through an unpatched vulnerability, an unauthorized administrative account, a compromised integration or a malicious file uploaded to the server.

In earlier stages of this campaign, researchers found evidence connecting infections with Magento file-upload vulnerabilities, including PolyShell (CVE-2026-48356) and SessionReaper (CVE-2025-54236).

These vulnerabilities are important because they can provide attackers with opportunities to establish access that survives later changes to the website.

2. Malicious JavaScript Is Added to CMS Content

Magento stores reusable content blocks in the cms_block database table. Attackers can exploit access to the database or administration system to modify those blocks.

When Magento renders an infected block on the storefront, the malicious JavaScript may execute automatically in the visitor's browser.

This means the infection might not be visible when a developer examines the website's theme files or installed extensions.

A store can therefore have clean-looking application files while still serving malicious content from its database.

3. The Loader Contacts an External Server

The injected JavaScript contacts infrastructure controlled by the attacker.

Rather than delivering the same response to every visitor, the remote server can select different behavior according to information supplied by the browser.

In the latest campaign, the loader gathers information that may reveal whether the visitor is using a real browser or an automated testing environment.

Examples include:

• Browser automation indicators associated with Selenium or WebDriver.
• Graphics hardware information exposed through WebGL.
• Screen resolution and device characteristics.
• Available processing cores and reported device memory.
• Browser language and time zone.
• Other browser characteristics useful for distinguishing visitors.

When an automated scanner visits the infected website, the malicious server may return an apparently harmless response.

A normal shopper may receive different content.

This explains why relying exclusively on an occasional external website scan is not sufficient to establish that a store is free from malware.

4. Malicious Code Can Persist in Browser Storage

One version of the loader uses the browser's localStorage mechanism and a key named fpCode.

The stored value can contain JavaScript that the infected website subsequently executes during later visits.

Unlike session storage, localStorage can persist beyond a single browsing session.

Consequently, blocking the remote malicious domain does not necessarily stop previously delivered code from executing while the infected loader remains on the website.

Removing the vulnerable loader prevents that particular execution mechanism from running on subsequent page loads. However, it does not establish that the server itself is clean or that the attacker has lost access.

5. A Hidden Backdoor Allows the Infection to Return

The final problem is persistence.

If criminals retain a webshell, unauthorized administrator account, compromised SSH key or another means of writing to the store's database, they can reinsert malicious content after it has been removed.

They may also replace the original malicious domain with another address, making a previous blocklist ineffective.

This is why deleting a suspicious script is not the same as removing the compromise.

Which Malicious Domains Are Associated With the Campaign?

Sansec identified several domains used during different phases of the operation.

The following indicators can help store administrators investigate suspicious website content, browser requests, server logs and security monitoring reports.

Suspicious domain	First observed on stores	Number of stores identified
manulfie.click	July 2025	863
neswnsssn.click	December 2025	494
lanhd6549tdhse.top	March 2026	355
additionalver.com	June 2026	246
deepveindrilling.com	October 2026	83

The figures overlap because some stores were infected across multiple waves. They must not be added together to estimate the total number of affected websites.

Two additional domains, hdfdsi84j3h.top and c85grt98sd.com, were also observed on a smaller number of stores.

Searching for these domains is useful, but a negative result does not prove that a website is secure. Attackers may encode domain names, change their infrastructure or use different malicious scripts.

How to Check Whether Your Magento Store Is Infected

Store owners should begin with a structured inspection of the database, administrative accounts, server files and browser behavior.

If there is reason to believe the store has been compromised, preserve the original environment and relevant logs before making changes. Read-only searches can support the investigation without modifying evidence.

Step 1: Inspect Magento CMS Blocks

Open the Magento administration panel and navigate to the CMS block management area, normally found under Content > Elements > Blocks.

Review unfamiliar blocks and recently modified content, particularly blocks displayed across multiple pages.

Suspicious characteristics include:

• Unknown external JavaScript sources.
• Encoded JavaScript embedded in otherwise ordinary HTML.
• Unexpected references to localStorage.
• Scripts that create invisible HTML elements.
• JavaScript event handlers with no legitimate storefront purpose.
• Content changes that cannot be linked to an authorized administrator.

For a more systematic inspection, a database administrator can execute the following read-only SQL query:

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

This query searches for several known patterns associated with the campaign.

If the Magento installation uses a custom database table prefix, the table name must be adjusted accordingly.

The update_time field may help investigators identify when suspicious content was last modified. The timestamp should be compared against authorized website changes, database logs and any other available evidence.

A match requires investigation rather than automatic deletion. Likewise, no matches should not be interpreted as proof that the store has not been compromised.

Step 2: Inspect CMS Pages

Attackers can also hide malicious code in ordinary pages rather than reusable blocks.

Run a similar inspection against Magento's cms_page table:

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

Examine suspicious results alongside the actual page content and the website's change history.

Because this campaign has also used encoded destinations, searches based on readable domain names alone are insufficient.

Step 3: Search for Suspicious Files and Webshells

Some Magento compromises involve malicious files disguised as normal media uploads.

Sansec documented a case in which webshells appeared as PNG image files inside the directory:

pub/media/custom_options/quote/

Other upload locations can also require inspection.

From the Magento installation directory, an administrator with authorized shell access can list files in the locations identified by researchers:

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

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

These commands list files; they do not delete them. The absence of a directory should be assessed against the store's configuration.

Files discovered through these searches must be examined carefully. Legitimate customer uploads and application files can exist in some of these locations.

Do not assume a file is harmless simply because its name ends in .jpg or .png. File extensions do not establish what a file actually contains or whether the server is configured to execute it.

A complete investigation should also inspect scheduled tasks, running processes, writable directories, SSH access and suspicious files outside the public document root.

Step 4: Audit Administrator Accounts

Review all Magento administrator accounts and their assigned permissions.

Pay particular attention to:

• Accounts created without an approved request.
• Users that no longer belong to the organization.
• Unexpected changes to administrator privileges.
• Unfamiliar email addresses associated with privileged accounts.
• Login activity from unusual locations or networks.
• New integrations or API credentials without a documented business purpose.

The presence of an unauthorized administrator account should be treated as a serious security incident.

Before removing suspicious accounts, preserve relevant records so investigators can establish when access was created and which actions were performed.

Step 5: Review Scripts Loaded by the Browser

Use browser developer tools to inspect network requests made by the storefront, especially during cart and checkout interactions.

Look for connections to unfamiliar domains, unexpected scripts and suspicious redirects.

Compare the findings with an inventory of approved payment, analytics, advertising and customer-service integrations.

However, the campaign's browser fingerprinting means that automated testing tools may not always receive the same content as ordinary customers.

When compromise is suspected, perform behavioral analysis in an isolated investigation environment rather than exposing personal devices or genuine payment information to potentially malicious code.

How to Remove the Malware and Secure a Compromised Magento Store

Successful recovery requires more than identifying the visible JavaScript injection. Every remaining route available to the attacker must be investigated and closed.

1. Contain the Incident Before More Customers Are Exposed

If active malicious JavaScript or unauthorized payment-page modifications are confirmed, immediately assess whether the storefront or checkout must be temporarily disabled.

Continuing to accept payments through a potentially compromised checkout can expose additional customers.

Coordinate containment with the hosting provider, technical team and payment processor. Restrict administrative access to trusted personnel and prevent unauthorized changes while evidence is collected.

A temporary protective firewall rule may reduce exposure, but it does not remove malicious database entries or existing backdoors.

2. Preserve Evidence and Determine the Scope

Before cleaning the website, securely preserve relevant database contents, application files, server logs and administrative activity records.

Where possible, take a consistent snapshot of the affected environment and store the evidence in a location that the compromised server cannot modify.

Investigators should establish:

• The earliest reliable indication of unauthorized access.
• Which administrator accounts or credentials may have been compromised.
• Which files and database records were modified.
• Whether suspicious scripts appeared on checkout or payment-related pages.
• Whether customer information may have been accessed or transmitted.
• Whether additional malware remains on the server.
• How the attackers initially entered and maintained access.

The timeline matters because restoring an old backup does not guarantee recovery. A backup created after the initial intrusion may already contain the attacker's access mechanisms.

3. Remove Unauthorized Database Content

Once evidence has been preserved and the suspicious content identified, remove the malicious code from affected CMS blocks and pages.

Restore legitimate content from a trusted version, where available.

Inspect other locations capable of inserting scripts into storefront pages, including:

• HTML header and footer configuration.
• Store-view-specific settings.
• Custom theme components.
• Third-party modules.
• Tag management configurations.
• Custom JavaScript inserted by extensions.
• Other database-controlled storefront content.

After the cleanup, refresh the necessary Magento caches and verify the rendered storefront.

Removing the visible loader is an essential containment measure, but it is not sufficient grounds to reopen an affected checkout while the possibility of persistent access remains unresolved.

4. Eliminate Server-Side Backdoors

Inspect suspicious PHP files, unexpected executables, scheduled jobs, modified application files and unauthorized system accounts.

Also review:

• Unknown SSH public keys.
• Unexpected changes to file permissions.
• Unapproved startup services.
• Unfamiliar background processes.
• Database accounts with excessive privileges.
• Files outside the website directory that belong to the store's operating-system account.

If the integrity of the server cannot be established reliably, rebuilding the application on a fresh, secured environment is often safer than attempting to clean every suspicious file individually.

Application code should come from verified distribution packages or trusted version-control repositories. Extensions and uploaded files must be checked before being transferred to the replacement environment.

Adobe's official guidance for responding to Adobe Commerce security incidents also recommends auditing accounts, application code and database configuration, resetting credentials and rebuilding from clean sources when necessary.

5. Apply the Necessary Magento Security Updates

Determine the exact Magento or Adobe Commerce version, installed security patches and relevant extensions before applying updates.

Two vulnerabilities deserve particular attention in the context of this campaign.

Vulnerability	Identifier	Required action
PolyShell	CVE-2026-48356	Verify that the applicable Adobe security update addressing unrestricted file uploads has been installed.
SessionReaper	CVE-2025-54236	Confirm installation of the relevant security update or supported hotfix.

For PolyShell, Adobe published security bulletin APSB26-73, which addresses CVE-2026-48356 among other vulnerabilities. The affected versions and available updates are detailed in the official Adobe security bulletin APSB26-73.

For SessionReaper, administrators should verify that the protections associated with APSB25-88 are present.

These are not the only Magento vulnerabilities requiring attention. Stores must also be assessed against subsequent security advisories applicable to their exact release branch.

Installations that can no longer receive security support should be migrated to a supported release.

Important: Applying a security patch closes the vulnerability it addresses. It does not automatically remove malware, revoke stolen credentials or invalidate backdoors created before the update.

6. Rotate Passwords, Keys and Integration Credentials

Once the environment is secured, replace credentials that may have been exposed.

The process should cover:

• Magento administrator passwords.
• Database credentials.
• SSH and hosting access credentials.
• API tokens and integration secrets.
• Payment provider credentials and relevant access tokens.
• Third-party service credentials stored on the server.
• Any compromised deployment or automation credentials.

Remove unauthorized accounts and revoke unknown access keys.

Invalidate sessions where compromise is suspected and ensure that legitimate administrators use multi-factor authentication.

Credential changes should be performed through a trusted device or clean administration environment. Changing a password while an attacker still controls the server may expose the replacement credentials.

Where application encryption keys may have been exposed, assess the appropriate rotation procedure and its effect on existing encrypted data and integrations.

7. Verify the Store Before Restoring Normal Operations

Before reopening a compromised checkout, complete a controlled verification process.

Confirm that:

• Previously identified malicious scripts are no longer present.
• Unknown external domains are no longer being loaded.
• No unauthorized administrator accounts remain.
• Unapproved server processes and scheduled tasks have been removed.
• Suspicious files and application modifications have been investigated.
• Required security updates have been installed.
• Payment integrations use valid, newly secured credentials where necessary.
• Checkout pages load only authorized resources.
• Test transactions follow the expected payment flow.
• Security monitoring detects unexpected changes.

Verification should cover the complete application and relevant server directories, not just files inside the web root.

A single clean scan cannot establish that every persistence mechanism has been removed. Recovery should be supported by evidence that the original intrusion route has been closed.

Why Updating Magento Alone Does Not Solve the Problem

One of the most revealing findings from the Sansec investigation involved a store running Magento 2.4.7-p10 with no missing core patches.

On October 23, 2026, the store began serving the new deepveindrilling.com loader even though it had passed a clean scan approximately one hour earlier.

Earlier investigations had identified an unauthorized administrator account in September and a GSocket backdoor later that month.

The case demonstrates how attackers can maintain access independently of the original vulnerability.

Consider a simplified scenario:

1. An attacker exploits an unpatched vulnerability and obtains server access.
2. The attacker creates another access mechanism, such as a hidden account or webshell.
3. The store owner installs the missing security update.
4. The original vulnerability is closed, but the unauthorized access mechanism remains.
5. The attacker uses that access to inject malicious code again.

The final result is a patched store that is still compromised.

This distinction is essential when assessing website security. Patch management prevents known attacks, while incident response identifies and removes damage from attacks that have already succeeded.

How to Prevent Magento Malware from Returning

Once a compromised store has been recovered, security measures should focus on making unauthorized changes more difficult and detecting them quickly.

Keep Magento and Extensions Updated

Maintain a reliable inventory of the Magento version, extensions, integrations and installed security patches.

Review security announcements promptly and test important updates in a staging environment before deployment.

Critical security patches should be prioritized according to exposure and actual exploitation risk rather than postponed until a routine maintenance window.

Restrict Administrative Access

Grant each user only the permissions necessary for their responsibilities.

Require multi-factor authentication for privileged accounts and remove unused administrative access immediately.

Where operationally practical, restrict administrative interfaces through a VPN, trusted network or other access-control mechanism.

Protect Upload Directories

Ensure the web server does not execute uploaded files as application code.

Use appropriate upload validation, safe file handling and restrictive permissions.

Application directories that should be read-only during normal operation should not remain unnecessarily writable by the web server.

Monitor Website Files and Database Changes

Traditional file-integrity monitoring is valuable but cannot detect every database-based injection.

For Magento stores, monitoring should include changes to:

• CMS blocks and pages.
• Administrator accounts and privileges.
• Store configuration.
• Application code and extensions.
• Scheduled tasks and server startup mechanisms.
• Payment-related scripts and browser resources.

Security alerts should be reviewed by a person or team responsible for investigating suspicious events.

Implement a Carefully Configured Content Security Policy

A Content Security Policy, commonly called CSP, helps control which resources a browser is permitted to load or execute.

Restricting script execution to approved sources can reduce exposure to some forms of unauthorized JavaScript injection.

However, CSP requires careful implementation and testing. Overly permissive rules weaken its effectiveness, while incorrectly restrictive settings can break legitimate payment functionality.

A CSP should therefore be treated as one protective layer rather than a replacement for server security, patch management or malware removal.

Control Third-Party Scripts

Advertising pixels, analytics services, customer-support widgets, marketing tools and payment integrations can introduce scripts into an online store.

Maintain an inventory of scripts that are authorized to run, particularly on checkout pages.

Review whether each integration is necessary and whether its functionality can affect payment data or customer information.

Where appropriate, use integrity verification and monitoring that detects unexpected script or HTTP header changes.

PCI DSS includes requirements addressing payment-page script management and tamper detection. The exact validation obligations depend on the merchant's payment integration and compliance arrangements. Further clarification is available in the PCI Security Standards Council's guidance on e-commerce payment-page scripts.

Monitor the Actual Customer Experience

Some malicious scripts deliberately identify automated browsers and avoid revealing their full behavior to scanners.

Security monitoring should therefore include more than server-side malware signatures.

Browser-level monitoring can help identify unexpected requests, unauthorized scripts, altered payment forms and unusual redirects.

Testing should include representative storefront pages and the complete checkout process, with safeguards that prevent real payment details from being exposed during security investigations.

Maintain Recoverable, Verified Backups

Keep backups outside the compromised server's control, restrict access to them and periodically test restoration.

Backups should cover both application files and the database.

Preserve sufficient recovery history to investigate earlier infections, but remember that older backups may already contain malware.

Every restored environment must be checked and secured before it is returned to production.

What Should Store Owners Do if Customer Payment Information May Have Been Exposed?

A confirmed website compromise does not automatically prove that credit card information was stolen.

However, malicious code executing in a customer's browser can create opportunities to intercept sensitive information, depending on the checkout architecture and the behavior of the malicious payload.

If an investigation identifies unauthorized payment-page scripts, suspicious data transfers or other evidence suggesting potential exposure, the store owner should promptly involve the payment processor and qualified incident-response personnel.

The investigation should establish:

• When the suspicious code first appeared.
• Which checkout pages were affected.
• Whether cardholder information was accessible to the malicious code.
• Whether the script transmitted information to an unauthorized destination.
• Which transactions or customers may have been affected.
• Whether payment-provider, card-network or legal notification obligations apply.

Notification requirements vary by jurisdiction, the type of information involved and the merchant's contractual responsibilities.

Businesses operating under the GDPR may have personal-data breach reporting obligations when the relevant legal conditions are met.

The appropriate response should be based on verified evidence and applicable obligations, not an assumption that every visitor to an infected store had payment information stolen.

Does This Campaign Affect WooCommerce, Shopify or Other E-Commerce Platforms?

The reported campaign predominantly concerns Magento and Adobe Commerce installations. Sansec's published findings do not establish that the same operation compromised WooCommerce or Shopify stores through these Magento-specific vulnerabilities.

Nevertheless, the underlying security risks are relevant to other e-commerce platforms.

Any website that allows unauthorized JavaScript to be inserted into pages may expose customers to malicious redirects, fraudulent forms or other browser-based attacks.

Similarly, stolen administrator credentials, vulnerable extensions and compromised hosting environments can threaten stores regardless of the platform.

Platform-specific security controls differ, but several principles remain consistent:

• Protect accounts with strong authentication and appropriate permissions.
• Apply security updates promptly.
• Review third-party applications and integrations.
• Monitor changes to checkout functionality.
• Investigate suspicious website behavior rather than relying only on visual inspection.
• Remove unauthorized access mechanisms before declaring an incident resolved.

Frequently Asked Questions About Magento Malware and Backdoor Removal

How can I tell if my Magento store has been hacked?

Inspect CMS blocks, CMS pages, administrator accounts, server files, scheduled tasks and browser network requests. Unexpected external scripts, unexplained database modifications, unauthorized accounts and suspicious background processes are warning signs. A clean scan alone cannot rule out a compromise.

What is deepveindrilling.com?

Deepveindrilling.com is a malicious JavaScript loader domain associated with an ongoing Magento-focused campaign investigated by Sansec. It was registered on October 6, 2026, and subsequently detected in CMS blocks on 83 online stores. The loader can communicate with attacker-controlled infrastructure and select responses according to browser characteristics.

Were 953 stores hacked in October 2026?

No. The figure of 953 refers to the broader campaign tracked since July 2025. The newest domain was detected on 83 stores, including 60 stores that had previously carried earlier malicious loaders. The figures describe identified infections across time, not 953 newly compromised stores during October.

Can attackers steal credit card information using JavaScript?

Yes. Malicious browser scripts can potentially intercept payment information when the payment flow exposes that data to the compromised page. They may also create fraudulent forms or redirect customers to deceptive websites. However, the presence of the latest Magento loader does not by itself establish that payment details were stolen.

Does updating Magento automatically remove malware?

No. An update may fix the vulnerability used for initial access, but it does not necessarily remove unauthorized accounts, malicious database content, webshells or stolen credentials. Those elements require separate investigation and remediation.

Can a Magento store be infected even if all core security patches are installed?

Yes. A previously compromised store may still contain persistent unauthorized access. Attackers may also exploit vulnerable extensions, compromised credentials or other weaknesses outside the Magento core. Patch status is important but does not independently establish the integrity of the entire environment.

Is blocking deepveindrilling.com enough to protect customers?

No. Blocking the domain may interrupt one part of the known malicious infrastructure, but previously delivered browser code, alternative domains and server-side backdoors can remain relevant. The malicious content must be removed and the attacker's underlying access eliminated.

Should an infected store be restored from a backup?

A verified clean backup can support recovery, but restoring it without identifying and closing the original intrusion route may lead to another compromise. Backups should be assessed for malware and the restored environment should be fully patched, secured and tested before returning to service.

How often should an online store be scanned for malware?

Continuous monitoring of important changes is preferable to relying only on occasional manual checks. Security scanning, file-integrity monitoring, administrative activity reviews and payment-page monitoring provide complementary protection. The appropriate schedule depends on the store's exposure, transaction volume and risk profile.

The Most Important Lesson: A Clean Website Is Not Necessarily a Secure Website

The Magento campaign affecting 953 online stores demonstrates how attackers can turn an initial security weakness into long-term control of an e-commerce website.

By placing malicious loaders in CMS content, selectively serving scripts to visitors and retaining access through hidden accounts or backdoors, criminals can make a compromised store appear normal long after the original intrusion.

The fact that some affected stores were reinfected after security updates illustrates an important distinction between preventing an attack and recovering from one that has already happened.

For an online store suspected of compromise, a reliable recovery process must identify the intrusion route, preserve evidence, remove malicious content, eliminate persistent access, update vulnerable components, rotate exposed credentials and verify the entire checkout process before normal operations resume.

The goal is not merely to remove the malicious script visible today. It is to ensure that the attacker no longer has the ability to put it back tomorrow.