A credit card skimmer — most commonly associated with the Magecart threat group — is a piece of malicious JavaScript injected into your website that silently copies payment card details as customers type them at checkout. If you suspect your site has been compromised, you need to act immediately: every minute the skimmer runs, real customers are losing real money. This guide walks you through exactly how to find it, kill it, and lock your site down so it cannot return.

What Is a Magecart Credit Card Skimmer?

Magecart is an umbrella term for a collection of cybercriminal groups that specialise in web skimming — injecting malicious JavaScript into e-commerce checkout pages to harvest card numbers, CVVs, expiry dates, and billing addresses in real time. The stolen data is silently exfiltrated to an attacker-controlled server while the legitimate transaction completes normally, so victims have no idea anything went wrong.

How does the skimmer get onto your site?

Attackers typically gain access through one or more of these vectors:

  • Compromised CMS credentials — weak or reused admin passwords brute-forced or phished
  • Vulnerable plugins or extensions — outdated WooCommerce, Magento, or PrestaShop modules with known CVEs
  • Third-party supply-chain compromise — a JavaScript library or tag-management script you load from an external CDN is itself infected
  • Hosting-level breach — shared hosting or a compromised FTP/SFTP account
  • Stolen SSH or database credentials — often obtained via credential-stuffing attacks

CISA and the FBI have both issued advisories on Magecart-style attacks, noting that e-commerce platforms running outdated software are the most common targets.

Step 1: Take Immediate Containment Actions

Do not wait until you fully understand the scope of the attack. Start containing damage right now.

Put your checkout page in maintenance mode

Disable the checkout process so no additional customers can submit payment details while you investigate. Most platforms have a built-in maintenance mode:

  • Magento 2: php bin/magento maintenance:enable
  • WooCommerce: Install a maintenance-mode plugin, or add define('WP_MAINTENANCE_MODE', true); temporarily to wp-config.php (not a native WP constant — use a trusted plugin like "WP Maintenance Mode")
  • PrestaShop: Shop Parameters → General → Maintenance mode → Yes

Notify your payment processor

Call your payment gateway (Stripe, PayPal, Authorize.Net, etc.) immediately. They can flag potentially compromised cards and may have seen fraudulent activity already. Do not delay this call.

Preserve evidence before you clean

Before touching any files, take snapshots:

bash

Example: archive your web root for forensic review

tar -czf /tmp/site-backup-$(date +%Y%m%d).tar.gz /var/www/html/

Make a copy of your access logs, error logs, and any available database dumps. You will need these for your incident report and potentially for legal compliance (PCI DSS, GDPR).

Step 2: Detect the Credit Card Skimmer

Manually inspect your JavaScript files

Magecart skimmers hide in .js files, inline <script> blocks on checkout templates, and sometimes inside theme or plugin files. Look for:

  • Obfuscated code — long strings of eval(), atob(), String.fromCharCode(), or hex-encoded payloads
  • Unexpected external domains — script tags or fetch()/XMLHttpRequest calls pointing to domains you don't recognise
  • Form-sniffing patterns — code that references document.querySelector, addEventListener('submit'), or targets fields named card, cvv, ccnumber, expiry
  • Base64 strings — decode any suspicious atob() arguments to reveal hidden URLs

A quick grep across your web root is a good starting point:

bash grep -rn "atob|eval(|fromCharCode|document.write" /var/www/html/ --include=".js" --include=".php" --include="*.html"

bash

Also search for exfiltration patterns

grep -rn "XMLHttpRequest|fetch(" /var/www/html/ --include="*.js" | grep -v "node_modules"

Check your checkout page source in a browser

  1. Open your checkout page in a browser and view the full page source (Ctrl+U / Cmd+U).
  2. Copy the source into a text editor and search for <script tags.
  3. List every external domain referenced by a src attribute. Any domain you cannot explicitly account for is suspicious.
  4. Right-click → Inspect → Network tab → reload the page → filter by JS and XHR and watch for outgoing requests to unknown hosts.

Use online scanning tools

Several reputable services can scan your pages for known skimmer signatures:

  • Sucuri SiteCheck (sitecheck.sucuri.net) — free surface-level scan
  • MageReport (magereport.com) — Magento-focused, checks for known Magecart vectors
  • urlscan.io — submits a URL and analyses all network requests, scripts, and redirects
  • VirusTotal — scan individual JavaScript files for known malicious signatures

These tools are useful but not exhaustive — a custom or freshly written skimmer may not yet appear in signature databases.

Audit your database

Attackers frequently inject malicious code directly into the database rather than the filesystem, making file-level scans insufficient. For Magento:

sql -- Search for suspicious content in core_config_data SELECT * FROM core_config_data WHERE value LIKE '%eval(%' OR value LIKE '%atob(%' OR value LIKE '%<script%';

For WordPress/WooCommerce:

sql SELECT * FROM wp_options WHERE option_value LIKE '%eval(%' OR option_value LIKE '%atob(%'; SELECT * FROM wp_posts WHERE post_content LIKE '%<script%' AND post_type = 'page';

Review recently modified files

bash

Find files changed in the last 14 days

find /var/www/html/ -type f -newer /var/www/html/index.php -name ".js" -o -name ".php" | sort

Cross-reference results against your version-control history (Git log, if available) or a known-good backup.

Step 3: Remove the Skimmer

Remove malicious code from files

Once you have identified the infected file(s):

  1. Open the file in a text editor (or via SSH with nano or vim).
  2. Delete the injected block — it will typically be a self-contained obfuscated block that starts and ends cleanly.
  3. Restore from a verified clean backup if you have one — this is always preferable to manual editing.
  4. Verify the file's integrity against the official platform release package using checksums.

For Magento 2, you can verify core file integrity with:

bash php bin/magento module:status

Then compare against official Magento GitHub release checksums

Remove database injections

Run the inverse of your detection queries to update or delete malicious values:

sql -- Example: remove an injected script from a config value UPDATE core_config_data SET value = REPLACE(value, '<script src="https://malicious-domain.com/skimmer.js"></script>', '') WHERE path = 'design/head/includes';

Always take a database backup before running UPDATE or DELETE queries.

Remove unauthorised admin accounts

bash

Check for new admin users in Magento

SELECT * FROM admin_user ORDER BY created DESC LIMIT 10;

sql -- WordPress: check for recently created admin accounts SELECT user_login, user_registered FROM wp_users ORDER BY user_registered DESC LIMIT 10;

Delete any account you do not recognise.

Check for backdoors

Attackers commonly install a PHP web shell alongside the skimmer to maintain persistent access. Search for common web shell signatures:

bash grep -rn "system(|exec(|passthru(|shell_exec(|base64_decode(" /var/www/html/ --include="*.php"

Any legitimate application code triggering these hits should be known to you. Investigate anything unfamiliar thoroughly.

Step 4: Close the Entry Point

Removing the skimmer without closing the original vulnerability guarantees reinfection, often within hours.

Update everything

  • CMS core: Apply the latest security release immediately.
  • Plugins, extensions, themes: Update every one; delete any you are not actively using.
  • PHP version: Ensure you are running an actively supported PHP version (check php.net/supported-versions).
  • Server software: Update Apache, Nginx, and MySQL/MariaDB.

Rotate all credentials

  • Change all admin/backend passwords — make them long, random, and unique.
  • Rotate SSH keys and FTP/SFTP passwords.
  • Rotate your database password and update your application config file accordingly.
  • Revoke and reissue any API keys used by your payment integration.
  • Enable multi-factor authentication (MFA) on every admin account.

Audit third-party scripts (supply-chain hygiene)

The OWASP guidelines on third-party JavaScript explicitly recommend:

  1. Subresource Integrity (SRI): Add integrity and crossorigin attributes to every externally loaded <script> tag so the browser verifies the file hasn't changed.

html

<script src="https://cdn.example.com/library.min.js" integrity="sha384-" crossorigin="anonymous"></script>
  1. Content Security Policy (CSP): Implement a strict CSP header that whitelists only the specific domains your site legitimately loads scripts from.

Content-Security-Policy: script-src 'self' https://js.stripe.com https://www.google.com; object-src 'none';

A well-configured CSP is one of the single most effective defences against Magecart attacks — even if an attacker injects a script, the browser will refuse to execute it if the source domain is not whitelisted.

Step 5: Verify the Site Is Clean

Re-scan after cleanup

Repeat every scan you ran in Step 2 after cleaning. Do not re-enable checkout until all scans come back clean.

Monitor outbound network traffic

Ask your hosting provider or use a Web Application Firewall (WAF) — such as Cloudflare, Sucuri, or the Magento NGINX WAF — to log and alert on outbound connections from your web server to unexpected external hosts.

Set up file integrity monitoring

Tools like Sucuri, Wordfence (WordPress), or OSSEC monitor your filesystem and alert you when files change unexpectedly. This is invaluable for catching reinfection quickly.

Step 6: Fulfil Your Legal and Compliance Obligations

PCI DSS requirements

If you process card payments, you are subject to the Payment Card Industry Data Security Standard (PCI DSS). A skimmer incident likely triggers the following obligations:

  • Notify your acquiring bank and payment brands (Visa, Mastercard) immediately.
  • Engage a PCI Forensic Investigator (PFI) if required by your bank — they will conduct a formal forensic investigation.
  • Document your incident response thoroughly.

GDPR / data protection law

If any EU/UK residents' data was compromised, GDPR Article 33 requires you to notify your supervisory authority within 72 hours of becoming aware of the breach. Article 34 may require you to notify affected individuals directly if the risk to them is high. Consult a data protection professional immediately.

Notify affected customers

Even where not legally mandated, affected customers should be told:

  • What happened and when
  • What data may have been exposed
  • What steps you have taken
  • What they should do (monitor statements, contact their bank)

Be honest, direct, and timely. Attempting to conceal a breach causes far greater reputational damage than transparent disclosure.

Step 7: Long-Term Prevention

Minimise your attack surface

  • Use a hosted payment page or payment iframe (Stripe Elements, Braintree Drop-in UI, PayPal Checkout) so raw card data never passes through your server or JavaScript environment at all. This is the single most impactful architectural change you can make.
  • Reduce the number of third-party JavaScript dependencies to the absolute minimum.

Ongoing monitoring

  • Subscribe to security advisories for your platform (Magento Security Alerts, WooCommerce changelog, etc.).
  • Set up Google Search Console alerts — Google Search Central sometimes flags compromised sites.
  • Use a WAF with active Magecart/skimmer rulesets.
  • Schedule quarterly security audits or penetration tests.

Keep backups you can trust

Maintain offsite, versioned backups tested regularly for restoration. A clean backup from before the compromise is your best recovery asset.

Frequently Asked Questions

How do I know if a credit card skimmer has already stolen my customers' data?

You cannot determine the full extent of data theft from the server side alone — skimmers operate client-side and exfiltrate data directly from the browser to an external server. Review your server access logs for outbound connections, check the dates of any suspicious file modifications, and compare against when your last clean backup was taken. Assume any customer who checked out after the earliest possible compromise date may have had their data stolen, and notify them accordingly. A PCI Forensic Investigator can provide a more definitive timeline.

Can a credit card skimmer affect sites that use Stripe or PayPal?

It depends on how your integration is set up. If you use a hosted payment page or embedded iframe (Stripe Elements, PayPal Checkout) where the card fields are served directly from the payment provider's domain, a skimmer injected into your site cannot access the card data because it is isolated inside a cross-origin iframe. However, if your checkout uses a custom form where card numbers are entered directly on your domain and then submitted via the Stripe or PayPal API, a skimmer on your page can intercept the keystrokes before they are ever sent to the payment provider.

How long does it typically take for a Magecart skimmer to be discovered?

Research published by security firms suggests the average dwell time for Magecart skimmers is measured in weeks to months, with some compromises going undetected for over a year. Attackers deliberately keep their scripts lightweight and non-disruptive so the site functions normally. This is why proactive monitoring — file integrity checks, CSP reporting, and regular manual audits — is essential rather than waiting for customer fraud reports.

Do I need to take my site completely offline to remove a skimmer?

You do not need to take the entire site offline, but you should disable the checkout process until you have confirmed the skimmer is fully removed and the entry point is closed. Leaving checkout active while you investigate risks compromising additional customers. Most platforms allow you to put just the checkout or payment step into maintenance mode while the rest of the site remains accessible.

Will changing to HTTPS / SSL protect me from Magecart attacks?

No. HTTPS encrypts data in transit between the browser and your server, but a Magecart skimmer operates entirely within the browser, capturing data before it is ever encrypted and sent. HTTPS is essential for general web security, but it offers no protection against client-side JavaScript injection attacks. The most effective protections are a strict Content Security Policy, Subresource Integrity on external scripts, and using a hosted payment iframe so card data never touches your JavaScript environment at all.