WooCommerce Credit Card Skimmers: Detect and Remove Magecart

A credit card skimmer on a WooCommerce store is the digital version of a card reader glued onto an ATM. Malicious JavaScript sits on your checkout page, silently copies card numbers as customers type them, and ships the data to a server the attacker controls. Orders complete normally, nothing errors out, and the first sign of trouble is usually customers reporting fraudulent charges or your payment processor flagging your store as a common point of purchase. This guide covers how these skimmers get in, how to find them, how to remove them, and how to make your checkout a hard target.

What is Magecart-style skimming?

Magecart is the umbrella name for criminal groups that inject card-stealing JavaScript into e-commerce checkouts. The technique started on Magento (hence the name) but WooCommerce is now a primary target simply because it powers more stores than any other platform. The attack is quiet by design: the skimmer does not disrupt payment flow, it just duplicates the form data. A well-built skimmer can run for months before anyone notices.

How skimmers get into WooCommerce stores

Where skimmer code hides

• Theme files: extra JavaScript appended to functions.php, footer.php, or checkout templates.
• The database: injected into wp_options rows such as widget HTML, customizer custom scripts, or settings of plugins that let admins add code snippets.
• Fake plugins: a directory in wp-content/plugins/ with a plausible name like "WooCommerce Toolkit" that contains only the skimmer and a backdoor.
• Core file tampering: code inserted into WordPress or WooCommerce core files where nobody looks manually.
• Disguised assets: skimmers hidden inside files pretending to be images or fonts, loaded by a small injected loader script.
• Gateway form replacement: the real payment iframe is swapped for a lookalike form that captures the card, shows a fake error, then forwards to the real gateway so the customer just thinks the first attempt failed.

Signs your checkout is compromised

1. Customers report fraud on cards used at your store, especially cards used nowhere else.
2. Your payment processor or acquiring bank contacts you about elevated fraud rates.
3. Checkout loads JavaScript from a domain you do not recognize.
4. A card field appears when it should be inside the gateway's hosted iframe, or customers see a "card declined, try again" pattern on the first attempt.
5. File integrity checks fail on core or plugin files.
6. New admin users, unexpected plugins, or recently modified files you cannot explain.

How to detect a skimmer, step by step

1. Watch the network tab during a test checkout

Open your checkout in a private browser window with DevTools open on the Network tab. Go through a test purchase and review every outbound request. Everything should go to your domain, your payment gateway, and known services you added (analytics, chat, fonts). Any POST or image request carrying encoded data to an unfamiliar domain at the moment you submit card details is the skimmer phoning home. Attackers register lookalike domains, so read carefully: stripe-analytics.example is not Stripe.

2. Verify file integrity against official checksums

wp core verify-checksums
wp plugin verify-checksums --all
# List files changed in the last 30 days
find . -type f \( -name "*.php" -o -name "*.js" \) -mtime -30 | sort

3. Search for injection patterns

# Obfuscation primitives in PHP
grep -rn --include="*.php" -E "eval\s*\(|base64_decode|gzinflate|create_function" wp-content/
# Script injections stored in the database
wp db query "SELECT option_name FROM wp_options WHERE option_value LIKE '%<script%' AND option_value LIKE '%http%';"

4. Scan from both sides

Remote scanners see what browsers see and catch exfiltration domains; server-side scanners catch the PHP that generates the injection. Use both. You can start with our free website vulnerability scanner for the outside view, then run a server-side malware scan on the hosting account.

Removing the skimmer

1. Take the store into maintenance mode and snapshot files plus database for forensics.
2. Remove the injection everywhere it appears: theme files, database options, fake plugins, tampered core files. Reinstall core, WooCommerce, and all plugins from official sources rather than trusting cleaned copies.
3. Hunt the backdoor. Skimmer operators always leave a way back in. Check for webshells in uploads, rogue admin and API users, unauthorized application passwords, and scheduled tasks (wp cron event list) that recreate the infection.
4. Rotate every credential: WordPress admins, database, hosting, SFTP, payment gateway API keys, and WooCommerce REST API keys.
5. Verify clean with a fresh test checkout and the same network-tab inspection you used for detection.

If the store processes real revenue, strongly consider handing this to an incident response team instead of doing surgery on a live checkout yourself. Sucuri's malware removal service handles e-commerce infections daily, removes skimmers and their backdoors, and includes unlimited follow-up cleanups: if it comes back, they clean it again at no extra cost.

Your obligations after a card breach

A skimmer incident is a payment card data breach, not just a malware problem. Under PCI DSS you are expected to notify your payment processor or acquiring bank, and depending on your jurisdiction and customer base you may have legal notification duties (state breach laws in the US, GDPR if you serve EU customers). Your processor may require a forensic investigation for larger incidents. Do not quietly clean up and move on: undisclosed breaches surface later through fraud pattern analysis, and the penalties for concealment are worse than the breach itself.

Hardening your checkout against skimmers

Use a Content Security Policy

A CSP tells browsers which domains are allowed to run scripts and receive data from your pages. Even if a skimmer gets injected, a strict policy blocks the exfiltration:

Content-Security-Policy: default-src 'self';
  script-src 'self' https://js.stripe.com https://www.googletagmanager.com;
  connect-src 'self' https://api.stripe.com;
  frame-src https://js.stripe.com; base-uri 'self'; form-action 'self'

Adjust the allowlist to your actual gateway and tools, and test in Content-Security-Policy-Report-Only mode first so you do not break checkout.

Add Subresource Integrity to third-party scripts

<script src="https://cdn.example.com/library.min.js"
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
  crossorigin="anonymous"></script>

If the file changes upstream, the browser refuses to run it. This directly defeats supply-chain script tampering.

Lock down the platform

• Use hosted payment fields (gateway iframes) so card data never touches your DOM where possible.
• Add define( 'DISALLOW_FILE_EDIT', true ); to wp-config.php so compromised admin sessions cannot edit code from the dashboard.
• Enforce two-factor authentication for every admin and shop manager account.
• Delete inactive plugins and themes, and never install nulled plugins.
• Put a web application firewall in front of the store. Sucuri's website firewall blocks the plugin exploits and brute-force attempts that plant skimmers in the first place, and virtually patches new vulnerabilities before you can update.

Frequently asked questions

My gateway uses an iframe. Am I safe from skimmers?

Safer, not safe. Hosted fields keep card data out of your page's DOM, but skimmers respond by overlaying fake forms on top of the iframe or replacing it entirely, capturing the card, then passing the customer through to the real gateway. The page itself must stay clean.

Would PCI DSS compliance have prevented this?

PCI DSS requirements like file integrity monitoring, patching, and access control make skimming much harder, and newer requirements specifically target client-side script management on payment pages. But compliance is a baseline, not a guarantee. Most skimmed stores were "compliant" via a self-assessment questionnaire that did not reflect reality.

How long do skimmers stay undetected?

Weeks to months is typical. The attack does not break anything, so nothing prompts an investigation until fraud reports accumulate and get traced back to your checkout as the common purchase point.

Do skimmers affect stores that use PayPal redirects only?

Full-redirect flows (customer leaves your site to pay) have much less exposure since no card form exists on your domain. Attackers counter this by injecting a fake on-site card form ahead of the redirect. If your customers ever see a card field on your domain when they should not, that is an incident.

Can a malware scanner plugin find every skimmer?

No single tool can. Plugin scanners see files but run inside the compromised site, remote scanners see rendered output but not the server side, and heavily obfuscated or database-resident skimmers evade signature matching. Layer detection: integrity checks, remote scans, and periodic manual network-tab reviews of checkout.

Conclusion

Card skimmers are the most financially dangerous WordPress infection because the victims are your customers and the liability lands on you. Detection comes down to watching your own checkout like an attacker would: network requests, file integrity, and injected code in the database. Removal is only complete when the backdoor is gone and every credential is rotated. And prevention is a solved problem: hosted payment fields, CSP, SRI, 2FA, aggressive patching, and a WAF in front of the store remove nearly all of the attack surface skimmer gangs rely on.

Related reading: how to fix the Deceptive Site Ahead warning and the OWASP API Security Top 10 guide.