Magento and Adobe Commerce Card Skimmers
By Glenn Lyvers · 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.
Skimmers are increasingly loaded through tag managers rather than theme files. See Google Tag Manager malware for how to audit a container.
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.
More than malware
Most people meet me in an emergency. It isn’t all I do.
I’ve been building and repairing systems since 1995. Whatever brought you here, there’s a good chance I can help with the rest of it too — and you’ll be dealing with the same person either way.
Hacked, but not WordPress?
Joomla, Drupal, Magento, Shopify, PrestaShop, Laravel, Node, IIS and plain HTML — cleaned the same way, priced the same way.
Take a look →Custom builds & AI systems
Plugins, custom applications, website chatbots and automation — built to do exactly what you need, maintained by the person who wrote them.
Take a look →Servers, speed, SEO & accessibility
Migrations, faster load times, technical SEO and accessibility fixes. Measured improvements, with the numbers to show you.
Take a look →Better web hosting
Fast, secure hosting with SSL and backups included at no extra charge. Clear pricing, no long-term contracts, no surprises.
Take a look →Classes & free tools
Rather learn to handle it yourself? I teach this, and I give away the tools I built for my own cleanups.
Take a look →Something else broken?
Half my work is untangling what someone else started, gave up on, or broke. Describe it in plain words and I’ll tell you honestly.
Take a look →Tell me what’s wrong. I’ll tell you what it takes.
No queue, no call centre, no sales pitch — one person who answers, quotes honestly, and does the work.