WooCommerce site hacked: what to do in the first hour

My store has been hacked and I don't know what was touched

Something is wrong and you found out from someone else. A customer says your link sent them to a pharmacy or casino site. Google shows "This site may be hacked" under your listing. Chrome blocks the page with a red warning. There is an administrator in WordPress you never added. Orders stopped, or strange ones started. Your host suspended the account for sending spam.

The first hour decides how bad this gets. Much of the damage after a hack comes from the panic response: deleting files, reinstalling plugins and restoring an old backup before anyone knows how the attacker got in. That destroys the evidence, keeps the hole open and loses real orders.

Below is why it happens, then the order I work in.

Why it happens

Almost every WooCommerce compromise comes through one of a few doors:

• An outdated plugin or theme with a known vulnerability. Once a flaw is published, automated scanners try it against every WordPress site they can find, usually within days.
• A reused or exposed password for a WordPress admin, the hosting panel, SFTP or the email account that can reset them.
• Tools left open in hosting. A file manager plugin, an old phpMyAdmin, an installer script or a staging copy nobody remembers.
• A nulled premium plugin downloaded from a free site, with a backdoor already inside.

Once inside, attackers hide. They add an admin with an ordinary name. They drop PHP files in wp-content/uploads. They put code in wp-content/mu-plugins, which WordPress loads automatically and lists on a separate tab most owners never open. They store scripts in the database, add rewrite rules to .htaccess, and schedule tasks that put everything back after you delete it.

Many redirects are conditional. They only fire for visitors on a phone, or visitors arriving from a Google search, and they skip anyone logged in to WordPress. That is why it looks fine to you and broken to customers.

What fixing it involves

The first hour, in order

1. Contain it. Put the store in maintenance mode, or block public traffic at your host or Cloudflare while allowing your own IP. Customers should not land on a redirect or a skimmed checkout while you work.
2. Snapshot before you touch anything. Download the full file tree and a database dump. Copy the web server access and error logs too; many hosts rotate them after a few days. Keep this copy off the server. It is your evidence and your fallback.
3. Rotate every credential, from a clean device. Hosting panel, SFTP and SSH, the database user (then update wp-config.php), every WordPress administrator, payment gateway and other API keys, and the email account that receives password resets. Then regenerate the salts in wp-config.php (wp config shuffle-salts with WP-CLI), which logs out every session, including the attacker's.
4. Check the admin list. In Users, filter by Administrator, or run wp user list --role=administrator. Remove anyone you don't recognize. Check Shop Manager accounts too.
5. Check the checkout. Place a test order and watch the page source and network requests for scripts loading from domains you don't use. If card fields sit on your own page rather than in your gateway's hosted fields, a skimmer could read them. If you find one, tell your payment provider today. They need to know, and they will tell you what comes next.
6. Check what Google sees. Open Google Search Console, then Security and Manual Actions, then Security issues. It lists the problem and sample URLs. Search site:yourdomain.com for spam pages you never made.

At the end of the hour the store is closed to the public, you have a copy of everything, and the attacker's passwords and sessions no longer work. Now you can find the hole calmly.

Finding the entry point

I read the access logs around the first sign of trouble: POST requests to unusual files, requests to plugin paths, logins from unfamiliar IPs. I compare installed plugin versions against known vulnerabilities and look for anything abandoned or nulled. I ask who has had access and whether any password was reused elsewhere. I check the hosting panel for file manager tools and leftover installers.

Then I check integrity:

• wp core verify-checksums compares every WordPress core file against the official release.
• wp plugin verify-checksums --all does the same for plugins from the WordPress.org directory. Premium plugins are not covered, so I compare those against a fresh download from the vendor.
• find wp-content/uploads -name "*.php" should return nothing on a normal store.
• Everything in wp-content/mu-plugins gets read line by line.
• wp cron event list and the server crontab, for jobs you didn't create.
• .htaccess, .user.ini and php.ini in every directory, for redirects and auto_prepend_file lines.
• The database: wp_options, widgets and post content, for injected script tags and unknown URLs.

I test the redirects the way they are aimed: a real phone on mobile data, arriving from a Google search, logged out.

Clean restore or clean in place

A clean restore means a backup from before the first compromise, fresh copies of core, plugins and theme, and the orders, customers and content since that date moved across. It is the safer choice when the infection is spread wide or you can't date it.

Cleaning in place means removing each malicious file, entry and account, then reinstalling core and plugins from source. It keeps everything current, but it only works if every piece is found.

Either way, the entry point gets closed first. Otherwise you clean the same site twice.

After hour one

• Harden. Remove unused plugins and themes. Update the rest. Enforce two-factor login for every admin. Disable file editing in the dashboard with DISALLOW_FILE_EDIT. Block PHP execution in uploads. Give each person their own account with the lowest role that works.
• Monitor. File-change alerts, uptime checks, admin login alerts and daily off-site backups that you have actually restored once.
• Ask for review. Once clean, request a review in Search Console so the warning comes off your listing. If your host or a blocklist flagged the site, ask them to re-check too.

If the hack came with a wave of failed small orders, read how to stop a card-testing attack. If you want someone watching the store so this does not happen again, that is what security, infrastructure and site care covers. If you aren't sure your backups would bring the store back, read backups that actually restore.