Magento and Adobe Commerce Card Skimmers

By · Updated · 4 min read

Your payment processor has been in touch about fraud reports, or your bank has, or a customer has. Magento stores have been a primary target for card-skimming campaigns for years, and if you are reading this because someone raised a fraud pattern, treat it as urgent — every hour the code stays live is another set of card details taken from your customers at your checkout.

What a skimmer actually does

It is JavaScript that runs on your checkout page, reads the card details as the customer types them, and sends them to a server the attacker controls. The customer's order completes normally, the payment goes through, and nothing appears wrong to anybody. That silence is the point — a skimmer that broke checkout would be found the same day.

It usually captures more than the card number: expiry, security code, name and billing address, which together are everything needed for fraudulent transactions. And because it reads the values from the page before they are submitted, it works even when the payment itself is processed securely elsewhere.

Where skimmers hide in Magento

Injected JavaScript in template files is the direct route, particularly in checkout templates. But the more common and harder-to-find variants live in the database: Magento stores a great deal of configurable content and design settings in database tables, including blocks of markup and header or footer scripts, and a payload placed there is rendered into pages while leaving every file untouched.

Look also at third-party extensions, which are the usual entry point and sometimes the carrier. Look for malicious admin accounts and API keys, since Magento's API can be used to alter store content without any file access. And check for scripts loaded from external domains on your checkout pages, which is the most visible form of the attack.

Finding it

Start from the checkout page as a customer sees it. Load it in a browser with developer tools open, look at every script the page loads, and account for each one. A script from a domain that is not yours and not a service you deliberately integrated is your finding. Watch the network panel while filling the form with test data — a request going somewhere unexpected as you type is definitive.

Then search the database for script tags and for the domains you found, check template files for injected code, and review recently modified files across the install. My guides on injected JavaScript and WooCommerce skimmers cover the same techniques applied to other platforms, and the detection approach translates directly.

What to do immediately

Disable checkout or take the store offline. I rarely recommend downtime, but a live skimmer is a continuing harm to real people with real financial consequences, and lost sales for a few hours is the smaller cost by a wide margin.

Preserve evidence before you clean — files, database and logs — because you will need to establish when the skimmer went live, and that date determines which customers were affected. My guide on preserving evidence covers doing it quickly. Then notify your payment processor and acquiring bank, which is usually a contractual requirement and is in any case the sensible early move.

Cleaning it out

Update Magento to a current patched version, since an outdated install is the most common entry point. Replace core files from clean sources, reinstall or remove third-party extensions, sweep the database for injected content, and delete admin accounts and API keys you did not create.

Rotate everything: admin passwords, database credentials, API keys, integration tokens, and the encryption key if you have reason to believe it was exposed. Then verify the checkout from a customer's perspective again, watching the network panel while entering test data, and keep watching for several weeks — skimmer campaigns reinfect aggressively.

Your obligations after a skimmer

This is the part that distinguishes a card skimmer from other malware. You have almost certainly had a payment card incident, which brings PCI DSS obligations, processor and acquirer notification requirements, and likely a forensic investigation depending on your transaction volume and merchant level.

You may also have breach notification duties to customers and regulators depending on where you and they are. My guides on PCI compliance after a skimmer and breach notification obligations cover both, and telling customers after a hack covers the communication. Get the technical cleanup done properly and quickly — that is what my malware removal service is for — and take advice on the compliance side rather than guessing.

Related reading: a compromised Magento admin, running Magento 1 in 2026. See also every platform I clean.

Common questions

How do I know if my Magento store has a skimmer?

Load your checkout as a customer, open developer tools, and account for every script the page loads. Then watch the network panel while typing test card data — a request to an unfamiliar domain as you type is conclusive. Fraud reports from customers or your processor are often the first signal.

My payment processor handles the card details. Am I still at risk?

Yes. A skimmer reads the values from the form fields in the customer's browser before they are ever submitted, so it captures the data regardless of how securely your processor handles what it receives afterwards. Hosted fields reduce but do not always eliminate the exposure.

Should I take the store offline?

For a confirmed live skimmer, yes, or at minimum disable checkout. Every additional order is another customer's card details taken. A few hours of lost sales is far cheaper than an extended exposure window, both in liability and in what you will eventually have to tell people.

Do I have to report this?

Almost certainly to your payment processor and acquiring bank, which is usually a contractual requirement. Depending on your transaction volume there may be a mandated forensic investigation, and depending on your jurisdiction there may be breach notification duties to customers and regulators. Take advice rather than assuming.

Why do Magento stores get targeted so heavily?

Because they process card details directly on pages the merchant controls, they are numerous, and many run outdated versions with unmaintained third-party extensions. That combination — valuable data plus a large population of unpatched installs — is exactly what mass campaigns look for.