Talk to an expert
PricingNewsTalk to an expert
Back to Newsroom
Threat Intel

Magento Skimmer Campaign Hits 953 Stores and Hides From Security Scanners

A long-running card-skimming operation has planted a JavaScript loader inside the content tables of nearly a thousand Magento stores. The code checks whether a visitor is a real shopper before it does anything, so routine scans come back clean while customers are still exposed.

4T4Tify Team4Tify
Oct 27, 2026·5 min read
Magento Skimmer Campaign Hits 953 Stores and Hides From Security Scanners

Magento Skimmer Campaign Hits 953 Stores and Hides From Security Scanners

A criminal operation that has been quietly planting malicious JavaScript in Magento stores since mid-2025 has now reached 953 online shops, and it is still running. The campaign stands out less for its scale than for its tradecraft: the injected code decides, on every page load, whether the visitor is a human shopper or an automated scanner, and it only serves the payload to humans.

What happened

The attackers store a small loader inside the Magento database rather than in a theme or module file. It lives in the cms_block table, the place where Magento keeps the static content blocks that are rendered on store pages. Because the loader is part of ordinary page content, it survives file-integrity checks and redeployments that only look at the codebase.

Before the loader does anything, it calls home to a traffic-distribution server and asks whether the current visitor should get the real script. Genuine shoppers receive the skimming payload; anything that looks like a crawler, a headless browser or a security scanner is handed a harmless no-op statement instead. A store owner who runs a quick external scan will often see a clean result on a store that is already compromised.

The group rotates its infrastructure every few months. The domain in use since October 2026 was found in the content blocks of 83 stores. Of those, 60 had previously run an older loader from the same operators, and 34 had been infected on and off since October 2025. In other words, many merchants were hit before, "cleaned" the visible script, and were reinfected because the underlying access was never removed.

The loader itself has evolved. The early version read a stored value called fpCode from the visitor's browser storage and replayed it on later page views, which kept the skimmer alive even when the attacker's domain went offline. In late October the operators rewrote it to send a full browser fingerprint to their server: it checks for automation markers such as navigator.webdriver, Selenium globals and ChromeDriver properties, and it collects the GPU name, screen size and time zone to tell real browsers apart from test harnesses.

How the stores were breached

This is a Magecart-style injection, and initial access has mostly come through file-upload weaknesses in Magento. In March 2026 the group pushed the loader into 471 stores in a single hour after dropping web shells through PolyShell, the unrestricted file-upload vulnerability tracked as CVE-2026-48356.

The loader was also found on 169 Magento 2 installations that were missing at least one core security patch. 102 of those also showed files uploaded through PolyShell or through SessionReaper (CVE-2025-54236), a critical flaw that lets an attacker take over customer sessions. Fully patched stores were not immune either: one shop on a current release received the loader an hour after a scan had come back clean, which points to stolen credentials or leftover backdoors rather than a fresh exploit.

Why it matters

Checkout skimmers steal card numbers directly from the customer's browser, so the merchant usually learns about it from the card networks or from angry customers, not from their own monitoring. This campaign makes that worse by actively defeating the one check most store owners rely on: an external scan of the storefront. A clean scan from an automated tool is no longer evidence that a Magento store is safe.

The reinfection numbers are the other warning sign. Removing an injected script without closing the hole that let it in, and without rotating the credentials the attacker already holds, buys a few weeks at most.

What to do

If you run or manage a Magento store, treat the following as a checklist rather than a suggestion:

  • Search the database, not just the files. Query the cms_block and cms_page tables for patterns such as fpCode, se_referrer and localStorage.getItem. Look at cms_block.content specifically.
  • Check for persistence. Review the admin_user table for accounts you do not recognise, look for unfamiliar processes on the server, and inspect upload directories such as pub/media/custom_options/ for web shells.
  • Rotate everything. After a cleanup, change the database, admin and API credentials. Deleting the script does not revoke the attacker's access.
  • Patch. Adobe's APSB26-73 bulletin addresses PolyShell and APSB25-88 covers SessionReaper. If you cannot upgrade immediately, put a web application firewall in front of the store to block known exploit attempts in the meantime.
  • Test like a human. When you verify a store, use a normal browser session with storage enabled, not only a headless scanner, and compare the scripts a real visitor receives against what your tooling sees.

Indicators to look for (defanged)

  • Loader domain: deepveindrilling[.]com (paths /?s=d35c5031 and /?s=49b7ca5f&fp=)
  • Traffic-distribution domains: additionalver[.]com, lanhd6549tdhse[.]top, neswnsssn[.]click, manulfie[.]click, hdfdsi84j3h[.]top, c85grt98sd[.]com
  • Payload hosts seen in December 2025: leqdger[.]click, crypto-insider[.]top
  • Decoy response served to scanners: QWE=123;
  • Browser storage keys: fpCode, 136c1e07507f4a97, 136c1e07507f4a98

Campaigns like this one get in through known, patchable flaws and then rely on nobody looking closely. Our vulnerability scanning service checks e-commerce platforms for exactly this class of exposure, from unapplied Magento security bulletins to writable upload paths, so that the gap is closed before someone else finds it.

SHARE