What ecommerce malware actually does
Ecommerce malware rarely announces itself with a broken checkout or a slow page. It usually looks like nothing at all. A payment skimmer sits quietly inside a checkout page and copies card data as customers type it. A server-side backdoor gives an attacker a way back into the store weeks after the original break-in. Both types of attack are designed to run undetected for as long as possible, because every extra day of silent access means more stolen payment data.
This attack family is commonly called Magecart, named after the group that popularized card skimming on Magento stores. The term has since broadened to cover any digital skimming attack, regardless of platform. Security researchers, including the team at Sansec, have tracked this activity since 2015 and describe two broad categories: browser-side skimmers that inject malicious JavaScript into the checkout page, and server-side malware that hides in files, database tables, or scheduled tasks on the hosting environment itself.
Why Magento and Adobe Commerce carry the largest share of risk
Magento and Adobe Commerce are open-source platforms with a large, mature extension ecosystem. That ecosystem is also the primary attack surface. A vulnerable third-party extension, an outdated core installation, or a compromised extension vendor can each give attackers an entry point. Sansec's research has documented several incidents that illustrate the pattern. CosmicSting (CVE-2024-34102) was a critical XXE vulnerability that, according to Sansec's tracking, led to roughly 5 percent of Adobe Commerce and Magento stores carrying a payment skimmer within weeks of disclosure. SessionReaper (CVE-2025-54236) followed a similar path, with widespread probing of unpatched stores after the details became public.
Sansec also uncovered a supply-chain compromise in 2022, when the distribution server of Magento extension vendor FishPig was breached and used to inject a remote access trojan into every store that installed or updated the affected extension. Incidents like this show that the risk extends beyond your own code. It includes every extension vendor your store depends on.
Platforms with a smaller or more tightly controlled extension ecosystem, such as Shopify, see fewer incidents of this specific kind, largely because the platform vendor controls more of the stack. That difference in architecture, not platform quality, explains most of the gap in reported attacks.
The three detection layers
Most ecommerce security discussions focus on the browser, because that is where a customer would notice something wrong. A large share of ecommerce malware hides on the server instead, in places an external scan cannot see. A realistic setup therefore combines three layers, each of which catches a different type of attack.
- Server-side scanning runs on the hosting server and inspects files, database content and scheduled tasks for known malware, unauthorized admin accounts and vulnerable extension versions.
- A web application firewall blocks known attack patterns before they reach the store. A platform-aware firewall can buy time while a store waits for an official patch.
- Checkout script monitoring watches which scripts load on payment pages and flags changes. It is the layer that catches browser-side skimmers.
Sansec's eComscan and Shield are examples of the first two layers for Magento and Adobe Commerce. Our Sansec page covers how its tools fit each platform and what the delivery around them involves.
Where this fits into PCI DSS and daily operations
PCI DSS version 4.0 added two requirements, 6.4.3 and 11.6.1, that specifically target payment-page tampering and unauthorized script changes. Both became mandatory in March 2025. Server-side malware scanning supports the underlying anti-malware requirement in PCI DSS, while browser-side script monitoring, sometimes called CSP monitoring, addresses the newer requirements more directly. Neither approach covers everything on its own, which is why most serious ecommerce security setups combine a server-side scanner, a web application firewall, and some form of client-side script monitoring.
Patching remains the first line of defence. A scanner or firewall buys time, but the hole stays open until the fix is installed. The same applies to the server underneath the platform. The PHP2Shell guide covers the October 2026 PHP vulnerabilities, which affect Magento stores at server level even when every Adobe patch is installed.
Evaluating a security monitoring vendor
Not every ecommerce security vendor covers the same threat model, so it helps to ask specific questions before committing to one. Ask whether detection runs server-side, browser-side, or both, since each catches different attack types. Ask which platforms are supported natively, because a tool built for Magento will not necessarily understand Shopware's architecture. Ask how often threat signatures are updated, and whether the vendor publishes its own research, since public disclosures are a reasonable proxy for how seriously a vendor treats the threat. Sansec, for example, publishes named vulnerability research such as CosmicSting, SessionReaper, and CronRAT, rather than only marketing claims, which gives you something concrete to verify.
Building a realistic response plan
A response plan should exist before an incident happens, not during one. At minimum, that means knowing who has admin access to the store, keeping the extension list current, and having a documented process for what happens when a scanner flags something. Nordic Web Team treats this as part of the surrounding delivery work around any Magento or Shopware project. Platform choice, hosting, and integration work through cloud infrastructure all shape how exposed a store actually is, and security monitoring should be planned alongside those decisions rather than added afterward.