Nearly 1,000 online shops hijacked through a Magento feature meant for banners
Attackers hid card-skimming code inside Magento's content blocks, a quiet corner of the storefront that most security scanners never think to read.

Key points
- Dutch security firm Sansec says 953 online stores, most of them built on Adobe's Magento software, have been quietly injected with card-stealing code since July 2025.
- The attackers hid their payload inside Magento CMS blocks, a legitimate feature shop owners use for banners and login hints, which almost no malware scanner inspects.
- No criminal group has claimed the campaign publicly, which fits the pattern of financially motivated skimmer crews that prefer silence over notoriety.
- Shoppers who entered card details on an infected store between July and now should assume the number is in criminal hands and ask their bank for a replacement.
- Adobe's own documentation confirms CMS blocks can carry raw HTML and scripts, which is exactly what makes them a useful hiding place.
Someone has spent the back half of 2025 quietly turning the checkout pages of nearly a thousand online shops into card-skimming machines. First reported by The Hacker News off research from e-commerce security firm Sansec, the campaign has hit 953 stores so far, the overwhelming majority running Magento, the shopping platform Adobe sells to mid-sized retailers.
The trick is straightforward and effective. Instead of dropping malicious files on the server, where a decent scanner would find them, the attackers tucked their code into a Magento feature called a CMS block.
What is a CMS block and why does it matter here?
A CMS block is a small, reusable chunk of a web page that shop staff edit from the admin panel: a promo banner, a shipping notice, the box on the login page that says "try our demo account." Per Adobe's own developer documentation, the content field of a block "may contain HTML markup and CSS styles," and hidden elements can be included in the response.
That means a block is a legitimate home for raw code. Security tools hunting for tampered PHP files or suspicious JavaScript on disk walk straight past it. The failure mode is boring: a feature built for marketers becomes a storage locker for attackers.
How does the attack actually hit shoppers?
When a visitor loads a page on an infected store, the poisoned CMS block quietly runs a small loader script in their browser. That loader pulls down the real skimmer, which watches the checkout form and copies card numbers, names, CVV codes and billing addresses to a server the attackers control. The shopper sees nothing unusual, the order goes through, and the card details leave with it.
This style of attack has a name in the industry: Magecart, after the loose collection of crews draining e-commerce sites this way since roughly 2015. Sansec has been a consistent voice documenting this ecosystem, and we reported in August on a critical Adobe Commerce flaw Sansec caught being actively exploited before Adobe had even acknowledged live attempts. What's new here isn't the goal; it's the hiding place.
Who is behind it?
Sansec hasn't pinned the campaign on a named group, and neither has anyone else. No leak site is bragging about it, which is normal for skimmer operators. They make money from every card they quietly resell, so attention is the last thing they want.
| Detail | What the research says |
|---|---|
| Infected stores | 953 |
| Main platform | Adobe Commerce / Magento Open Source |
| Campaign start | July 2025 |
| Hiding place | Magento CMS blocks |
| Attribution | None public |
What should shoppers and shop owners do?
If you bought something online between July and now and later spot a charge you don't recognise, call your bank and ask for a new card. That's the only reliable move, because there's no public list of the 953 stores.
If you run a Magento store, pull up every CMS block in your admin panel and read the raw content. Look for <script> tags or anything calling out to a domain you don't recognise. Check who logged into the admin panel over the summer, then rotate those passwords and turn on multi-factor authentication. Every postmortem on a breach like this says the same thing: the admin account had a weak password and no second factor.
Skimmers don't need a zero-day when a marketing feature will do.



