Recovery

My WooCommerce Store Has Been Hacked: Emergency Recovery Guide

By WebAdish

WooCommerce stores are targeted at a higher rate than standard WordPress sites because they hold what attackers want most — live payment flows, customer card data, and personal records. If your store has been compromised, every hour of continued trading increases customer harm and your legal exposure.

Key Takeaways
  • Disable checkout and notify your payment processor before doing anything else
  • JavaScript skimmers run silently — your store can appear normal while card data is being stolen
  • A forensic cleanup must find all backdoors, not just visible malware, or the site will be re-infected
  • UK businesses handling customer data have GDPR breach assessment obligations within 72 hours

Signs your WooCommerce store has been compromised

Some attacks are immediately visible. Others run silently for weeks. The most serious attack — a JavaScript payment skimmer — produces no visible symptoms at all. Your store processes orders normally while every card number entered at checkout is captured and sent to the attacker.

Signs to watch for:

  • Customers reporting card fraud shortly after purchasing from your store
  • Checkout redirecting to unexpected third-party sites or unfamiliar URLs
  • Google showing a "Deceptive site ahead" warning when visitors open your site
  • Your payment gateway flagging or suspending your merchant account
  • Unknown orders, refunds, or coupon codes appearing in WooCommerce admin
  • Unexpected admin user accounts in your WordPress dashboard
  • Your hosting provider suspending your account for malware or spam
  • A sudden drop in organic traffic or security warnings appearing in Google Search Console

If you are seeing any of the above, assume a breach until proven otherwise. If you are seeing none of the above but have reason to suspect compromise — a customer complaint, a hosting alert, a processor notification — treat it the same way. Skimmers are designed to be undetectable without active investigation.

Your first 30 minutes: limiting the damage

Do these in order. Every additional hour of live checkout on a compromised store increases the number of affected customers.

  1. Disable checkout or switch your payment gateway to test mode. If you cannot do this immediately, contact your hosting provider and ask them to block access to the checkout and payment pages at the server level while you investigate.
  2. Notify your payment processor immediately. Call them directly — do not use email for time-sensitive breach notifications. Stripe, PayPal, Worldpay, and Opayo all have dedicated fraud and security lines. Explain that you have identified a suspected security incident affecting payment processing. They will advise on next steps and whether your merchant account needs to be suspended.
  3. Take a backup of the infected state. Before cleaning anything, take a full file and database backup. This is your forensic record. You need it to understand the scope of the breach, establish which customer data may have been accessed, and meet your breach documentation obligations under GDPR. Do not use this backup as a restore point — it is infected.
  4. Change every credential. WordPress admin passwords, FTP/SFTP credentials, database password, and your hosting control panel password. An attacker with active server-level access can undo any cleanup in real time if you do not close their access route first.
  5. Document what you observe. Note when the compromise was discovered, what symptoms are visible, what plugins and themes are installed, and when each was last updated. This record supports your GDPR breach assessment, your payment processor report, and any professional recovery engagement.

GDPR and UK data protection obligations

If you process personal data about UK or EU residents — which every WooCommerce store does — a breach that may have exposed that data triggers assessment obligations under UK GDPR and the Data Protection Act 2018.

You are not automatically required to notify the ICO of every incident. The test is whether the breach is likely to result in a risk to the rights and freedoms of individuals. A breach involving payment card data or customer contact information (name, address, email, phone) typically meets this threshold. If the threshold is met, you have 72 hours from becoming aware of the breach to notify the ICO.

You should document your assessment either way — including incidents where you determine notification is not required. See our detailed article on whether you need to report a hacked website to the ICO.

Important: the 72-hour clock starts when you become aware of a breach that may meet the notification threshold — not when the breach is fully investigated. If you discover evidence of a breach today, start the clock today, even if investigation is ongoing.

What attackers target in WooCommerce stores

JavaScript payment skimmers

The most serious WooCommerce attack injects a small JavaScript snippet into your checkout page — typically into a plugin file, a theme file, or directly into your WordPress database options table. When a customer enters their card number, the skimmer captures it and sends it to an attacker-controlled server before the legitimate transaction processes. Your payment gateway processes the real transaction normally. The customer and you have no idea anything unusual happened.

Skimmers are designed to evade surface-level security scans. They are typically obfuscated or encoded, and may only activate on specific pages or for visitors arriving from certain browsers or referrers. Detecting a skimmer requires a source code inspection of the rendered checkout page as delivered to a browser — not just the server-side files.

Customer data exfiltration

WooCommerce order records contain customer names, delivery addresses, email addresses, phone numbers, and purchase history. For UK businesses, this data is protected under UK GDPR. Attackers who gain database access — via SQL injection or compromised credentials — will extract and export the customer table. There is often no visible sign this has occurred. The first indication may be customer complaints about spam or targeted phishing emails using their correct name and order history.

Redirect malware

Malware that redirects visitors — especially those arriving from Google — to phishing or spam sites. These redirects are typically conditional: they only fire for search engine traffic, so they are invisible when you visit your own site directly. Your customers click your Google result and land on a spam page. You visit the URL and see your normal store. This is a deliberate evasion technique and a common cause of Google Safe Browsing blacklisting.

The recovery process

Full forensic scan — not a plugin scan

Standard plugin-based scans (Wordfence, Sucuri, MalCare) compare files against known malware signatures. They catch many common infections but miss custom-built attacks, obfuscated injections, and database-level malware. A forensic scan inspects every file on your server, decodes obfuscated PHP, compares core and plugin files against official checksums, and reviews the WordPress database for injected content.

For WooCommerce stores where a skimmer is suspected, a forensic scan must also include inspection of the rendered checkout page source — what a browser actually receives when loading the payment form.

Remove all backdoors before cleaning the surface malware

A backdoor is hidden code that allows the attacker to re-enter even after you have removed all visible malware. Common WooCommerce backdoor locations include the wp-content/uploads directory (PHP files disguised as images), encoded PHP files inside plugin directories, modified WordPress core files, and injected content in the database options table.

Cleaning surface malware without removing all backdoors results in re-infection — typically within days. This is the most common reason WooCommerce recoveries fail.

Close the entry point

Identify and close the vulnerability that allowed initial access: an outdated plugin with a known CVE, a nulled or pirated theme, a compromised admin credential, or a vulnerable file upload handler. If the entry point is not closed, a new attacker — or the same one — will use it again.

Verify clean checkout before re-enabling trading

Run a test transaction end-to-end in a browser. Inspect the checkout page source code for any unexpected external scripts or resources. Run a final scan. Only then re-enable live payment processing.

Preventing a repeat incident

  • Web Application Firewall — Cloudflare or Sucuri in front of your store blocks the majority of exploit attempts before they reach WordPress
  • Remove every unused plugin and theme — deactivated plugins remain exploitable from the file system
  • Two-factor authentication on every WordPress admin account without exception
  • Payment page integrity monitoring — automated alerts when your checkout page JavaScript changes unexpectedly. This is the early warning system for skimmer attacks.
  • Security retainer — continuous monitoring means vulnerabilities are patched before attackers can exploit them, and incidents are detected in hours rather than weeks

WebAdish provides emergency hacked website recovery for UK businesses, including WooCommerce-specific forensic cleanup and payment page skimmer detection. If the incident is active, use the emergency recovery page. If you want protection before the next incident, see our security retainer or WordPress care plan options.

Related Recovery Resources

If this article is part of an active incident, use these core pages next.

Hacked Website Recovery UKWordPress Malware RemovalWhy Sites Keep Getting Hacked

Need Help With WordPress Security?

Get a professional security audit or speak to our team about protecting your WordPress site.

Request a Security Review
Chat with us