"This Site Contains Harmful Software": Inside a Real WooCommerce Malware Cleanup

We were recently called in to help an online store whose owner had just watched Google slap a "this site contains harmful software" warning across their business in search results — the red screen that stops shoppers cold before a single product loads. The site was slow, occasionally freezing, and a handful of customers had complained of being bounced to spam pages mid-visit. The owner had already run two plugin scanners and asked their host to "check for viruses," and everything had come back clean. It wasn't. What we found on this client's WooCommerce store was a hidden, multi-layered infection built specifically to survive exactly those checks — and it's a near-perfect illustration of why fixing a Google harmful software warning is almost never as simple as deleting one bad file. Here's exactly how this attack worked, why the usual tools missed it, and what a thorough WordPress malware removal actually involves.

The symptoms: a warning, a slow site, and vanishing customers

The first sign for most owners is never the malware itself — it's the fallout. On this store the pattern was textbook. In Chrome and Safari, the business's own listing carried Google's warning that the site contained harmful software. The site felt sluggish and would freeze for a beat on load. And most damaging of all, real customers were being redirected to spam while the owner — logged into their own admin — saw a site that looked perfectly normal. That gap between "it looks fine to me" and "my customers say it's broken" is the single most common reason a hacked store stays hacked for weeks. If any of that sounds familiar, our checklist of the warning signs your website has been hacked covers the symptoms worth acting on fast.

What this type of attack actually is

Underneath the symptoms, this was a JavaScript-injection attack wired to a traffic-direction system — think of it as a remote switchboard the attacker controls. The malware didn't carry a fixed payload of its own. Instead, it quietly phoned home to a command-and-control server on the attacker's side and ran whatever JavaScript that server sent back. That design is what makes these infections so dangerous: the attacker can change what your site does to visitors at any time, without touching your server again. One hour it's spam redirects; the next it's a fake "update your browser" prompt that installs malware on the shopper's computer; later it can flip to ad fraud or, on a store taking payments, a checkout card-skimmer quietly copying card numbers. Your website becomes a rented weapon pointed at your own customers.

The infected file didn't contain the attack. It contained a phone number for the attack — and dialed it fresh for every visitor.

Why it hid so well

This store wasn't infected in one obvious place. The malware came in three coordinated layers, each designed to defeat a different kind of inspection:

• A fake "cache/performance" plugin. It looked like a routine speed-optimization add-on, but its real job was to install the malware and then hide itself from the plugins list in the admin panel — so scrolling through installed plugins showed nothing wrong. Disguised plugins that conceal themselves and silently create attacker access are a documented, active technique, not a theory.
• Malicious code slipped into the theme's JavaScript. The attacker appended obfuscated code to a legitimate jQuery file the theme already loaded — scrambled and assembled from fragments at runtime so it never reads as recognizable malware when you open the file.
• Faked file timestamps. The tampered files were given modification dates far in the past, so the usual "show me everything changed recently" check — the first thing most people (and many tools) rely on — skipped right over them.

And then the cleverest part: cloaking. The malicious script checked who was visiting before it fired. If you were a logged-in administrator, a known search-engine crawler, or arriving from certain referrers, it stayed completely dormant — the site looked spotless. It only activated for ordinary shoppers. That's why the owner's own eyes, and even Google's crawler at times, saw a clean site while real customers got attacked. If your site is quietly sending visitors elsewhere, our breakdown of why your website is redirecting to spam explains exactly how this conditional hiding works.

The sneaky part most "fixes" miss: the CDN kept serving the infection

Here's the detail that traps even competent cleanups. This store sat behind a content delivery network — a CDN, the global cache layer most fast sites use to serve files quickly from a location near each visitor. The infected theme JavaScript file had been cached at the CDN's edge. So even after we had fully cleaned the origin server — the actual source files were spotless — the CDN kept handing visitors the old, cached, infected copy for up to roughly 24 hours. For that window the site was still attacking customers and still earning its Google warning, despite being "clean" by every check run against the server. A clean origin is not a clean site until the CDN cache is purged. Miss that step and you'll swear the site is fixed while it quietly keeps infecting people — and Google's re-scan will keep failing.

You can scrub the server spotless and still be dangerous. The internet was reading from a cached copy you never touched.

Why automated scanners and host security tools often fail

The owner's scans came back clean for a reason that's worth understanding, because it applies to most serious infections — not just this one. Automated scanners and host-level security tools lean heavily on pattern-matching: known malicious filenames, known bad code signatures, and recently-modified files. This attack was engineered to beat all three. The code was obfuscated and assembled from fragments, so it matched no known signature. It was appended to a file the scanner already trusted, so it wasn't a suspicious new file. Its timestamps were faked, so the recency check passed it by. And the fake plugin hid itself from the very admin list a scanner would enumerate. None of that means the tools are bad — they catch the common stuff well. It means they're a smoke alarm, not a forensic team, and a determined attacker builds specifically around them.

What a real, thorough cleanup involves

Removing an infection like this is a sequence, and the order matters as much as the steps. On this store, a proper cleanup looked like:

1. A full forensic scan of every file and the entire database — not just recently-changed files — to map the complete infection before touching anything.
2. Removing the injected code from the theme JavaScript, deleting the fake self-hiding plugin, and stripping out the rogue administrator accounts the attacker had created for re-entry.
3. Rotating every credential and secret — all admin and database passwords, hosting and FTP logins, and WordPress's security keys and salts — so any stolen login instantly becomes useless.
4. Verifying WordPress core-file integrity against the official checksums so any tampered core file is caught, and reinstalling plugins and themes from clean, verified sources.
5. Purging the CDN cache so the infected file stops being served at the edge — the step a server-only cleanup skips, and the reason the site had stayed dangerous.
6. Requesting a Google Safe Browsing review in Search Console to lift the blacklist, only after the site is independently verified clean.

That clean-first, review-second order is non-negotiable: a review requested on a still-infected site simply fails, and repeated failed requests slow future ones down. Our step-by-step guide to removing Google's "this site may be hacked" warning walks through the Search Console review process in detail. If you've been flagged and aren't confident you've found everything — and with cloaked, time-faked malware like this, almost nobody has — this is the point to hand it to professional malware cleanup rather than submit a review that's doomed to fail.

How to prevent it happening to your store

Almost every infection we clean traces back to the same short list of preventable gaps, and the fixes are unglamorous but genuinely effective:

• Keep WordPress core, every plugin, and every theme updated promptly — the overwhelming majority of hacked sites were running software patched weeks or months earlier.
• Use strong, unique passwords and turn on two-factor authentication for every admin account; credential-stuffing bots run around the clock.
• Keep admin accounts to the minimum, and review the user list regularly for accounts you don't recognize.
• Delete plugins and themes you don't use — an inactive plugin is still live, exploitable code sitting on your server.
• Keep off-site backups you can actually restore from, stored somewhere the site itself can't reach.
• Run ongoing security monitoring so a new infection is caught in minutes instead of being discovered by a customer, or by Google.

That last point is where most stores fall down. A one-time cleanup fixes today's infection; it does nothing about next quarter's unpatched plugin. The most reliable protection is ongoing website maintenance — updates applied on a schedule, backups verified, and monitoring that flags a change the moment it happens. For the stores we clean, rolling onto that kind of care plan is what turns "we got hacked again" into "we caught it in ten minutes." If you want to understand the root entry point better, our guide to how WordPress sites get hacked covers why outdated plugins are the number-one cause.

Quick answers to the questions owners always ask

How long until the Google warning disappears?

Once the site is genuinely clean and you've requested a review in Search Console, the "harmful software" and "this site may be hacked" warnings typically clear within about 24 to 72 hours of Google confirming the site is safe. The clock only starts once the site is actually clean — which is why a rushed, incomplete cleanup costs you far more time than a thorough one.

Will I lose my site or my data?

No. An infection like this is cleaned in place — we remove the malicious code and accounts and leave your real content, products, and orders untouched. We take a forensic backup before touching anything, both as evidence and as a rollback point, so there's a safety net the whole way through.

How did they get in, and how do I stop it recurring?

Almost always through outdated software or a weak password — a known vulnerability that automated attacks scan the entire web for, not a targeted hit on your business specifically. Recurrence is prevented by closing that exact entry point during the cleanup and then keeping the site updated and monitored on an ongoing maintenance plan so the next vulnerability is patched before a bot finds it.

If your store is flagged right now, this is fixable

A "this site contains harmful software" warning feels like the end of the world when it's sitting under your own business name — but it's a solved problem, and usually a fast one when it's done right the first time. That's exactly what our Code Red service is built for: get your hacked site cleaned the same day, with a full forensic scan, every backdoor and rogue admin removed, the CDN purged, the root cause closed, and the Google Safe Browsing review filed for you so the warning comes down. We'll tell you honestly where you stand before you spend a dollar — call us or use the contact form on our homepage. And if you'd rather never see that red screen again, we'll roll your store onto an ongoing care plan so the next attack is caught in minutes, not discovered by your customers.