What a card skimmer does

A card skimmer, often called a Magecart-style attack, is malicious JavaScript that copies what shoppers type into the checkout form (card number, expiry, security code, name and address) and sends it to the attacker. The order still goes through normally, so nobody notices until cards start being misused and a bank traces the common point of purchase back to your shop.

How skimmers get into WooCommerce stores

  • A vulnerable plugin or theme lets the attacker write files or settings.
  • A stolen administrator or hosting password gives direct access.
  • A compromised third-party script, such as a chat widget, analytics tag or library loaded from another domain, is changed at its source and every shop that loads it is affected.
  • A “nulled” premium plugin arrives with the skimmer, or a loader for it, already built in.

Where skimmers hide

  • In the database: a script stored in a WooCommerce or theme setting, a widget, or a custom-code option, so no file changes at all.
  • In theme files, usually functions.php or a footer template, often only printing the script on the checkout page.
  • In a plugin file, sometimes a fake plugin with a believable name.
  • Inside a legitimate-looking JavaScript file, appended to a minified library.

Many skimmers deliberately stay dormant: they only run on the checkout URL, skip logged-in administrators, or only fire once per visitor. Looking at your own checkout while logged in proves very little.

WooCommerce card skimmer detection: six practical checks

1. Keep an inventory of checkout scripts

List every script that loads on your cart and checkout pages, with its source domain and reason. In a private window, open your checkout, then the browser’s developer tools (Network tab, filtered by JS), and compare against your list. Anything new or unexplained needs an answer.

2. Scan files and the database for injected JavaScript

Search for <script, atob(, eval(, new WebSocket and unfamiliar domains in theme files and in wp_options and wp_posts. A scanner built for this helps: Silent Threads’s JS & Card-Skimmer Scanner (Pro) looks specifically for skimmer injections, and its Database Scanner (every plan) checks stored content.

3. Check file integrity

Compare WordPress core with the official checksums and reinstall WooCommerce and your payment plugin from their source if anything is in doubt. Core File Integrity runs on every plan; Premium Plugin Drift (Pro) watches paid plugins that have no public checksums.

4. Watch where data goes

Skimmers have to send data somewhere, often to a domain chosen to look like a real analytics or CDN address. Watch the outbound requests your checkout makes in the browser, and on the server watch for new outbound connections. Silent Threads’s Outbound Connection Monitor (Pro) flags connections your site didn’t make before.

5. Use a Content Security Policy

A Content Security Policy (CSP) header tells browsers which domains may run scripts and receive data on your pages. A strict policy on checkout blocks many skimmers from loading or sending data, and its violation reports show you attempts. Start in report-only mode, because a policy that’s too strict can break payment widgets.

6. Lock down who can add code

Turn on two-factor authentication for administrators and shop managers, remove accounts nobody uses, disable the theme and plugin file editor, and get an alert when a new administrator appears. The 2FA and the new-admin alert are on every Silent Threads plan.

Do hosted payment fields protect you?

Hosted payment fields or a redirect to the payment provider keep card data out of your page’s own form, which removes the easiest target and reduces your compliance scope. They don’t make you immune: a skimmer can replace the hosted field with a fake form, overlay it, or skim the address and email fields that remain on your page. Use hosted fields and monitor the page.

What PCI DSS 6.4.3 and 11.6.1 require for payment pages

PCI DSS version 4.0 added two requirements aimed squarely at skimming, which became mandatory on 31 March 2025:

  • 6.4.3: scripts loaded and run on the payment page must be managed. Each script is authorised, its integrity is assured, and there is an inventory with a written justification for each one.
  • 11.6.1: a change- and tamper-detection mechanism must alert on unauthorised changes to the security-relevant HTTP headers and the script contents of payment pages, as received by the shopper’s browser, at least weekly or as defined by your risk analysis.

Whether and how these apply depends on how you take payments and on your acquirer. Ask your payment provider which self-assessment questionnaire applies to you. A security plugin helps you detect changes; it doesn’t make you compliant on its own.

If you find a skimmer

  1. Take a full backup of files and database as evidence.
  2. Put checkout into maintenance, or switch to a redirect-based payment method.
  3. Tell your payment provider; they will advise on what happens next.
  4. Follow a full clean-up: how to remove malware from WordPress.
  5. Find and close the entry point before re-opening the checkout.

For the store-wide view, see WooCommerce security.

How we checked this guide

PCI DSS requirement summaries are paraphrased from the PCI Security Standards Council’s v4.0 standard; read the standard and talk to your payment provider for your exact obligations. This article is not legal or compliance advice. Plugin features are named with the plan that includes them.