Case study: how we fixed a malicious WordPress redirect (LiteSpeed Cache)

A WordPress site for a country leisure complex was redirecting visitors to third-party sites, including adult content, but only people who came from a smartphone, on mobile data, and for the first time, with no cookies. The owner and the developers saw a normal site, while Google Ads blocked the advertising account and the client lost money on ads. The cause was an old pirated (nulled) copy of the LiteSpeed Cache plugin with a known vulnerability. We found the code in two files out of 32,000, cleaned the site and closed the hole, and later the client moved to our Atom content management system.

What the client saw

A normal site: the admin panel worked, pages opened, and the owner never got redirected. Meanwhile, Google Ads blocked the advertising account. The ads stopped, and the budget spent on clicks that led to a malicious site can’t be recovered.

The hardest part was reproducing the problem. From a desktop, on Wi-Fi, or on a phone that had already visited the site, there was no redirect. It only fired when three conditions were met at once:

• a mobile device;
• mobile data rather than Wi-Fi;
• a first visit with no cookies, meaning a new visitor.

Malicious code hides like this on purpose. The site owner, admin and developer almost always visit from saved sessions and office Wi-Fi, so they see nothing. A new customer arriving from an ad on a smartphone is exactly who gets redirected.

How we found the malicious code

Once we knew who the site was redirecting, we stopped testing in the browser and started checking the server:

1. Pinned down the date of the hack. The attackers got in around April 20, 2024.
2. Compared files with a backup. The old server still had a backup from April 15, before the hack. We restored the site from it and compared all 32,000 files with the hacked version.
3. Found the difference in two files. Malicious code had been added to the theme’s functions.php and to the very top of WordPress’s own wp-includes/js/jquery/jquery-migrate.min.js. WordPress loads that script on almost every page, so the code ran everywhere.
4. Checked the users. A second administrator, wp-configuser, had appeared in the admin panel. Nobody had created it.

Checking recently modified files is what pointed us in the right direction. But it only worked once we knew what we were looking for: on a site with tens of thousands of files, “something changed” turns up hundreds of matches.

Where the hack came from

The site ran LiteSpeed Cache, a popular caching plugin with more than 5 million installs. It isn’t a shady plugin; it’s a legitimate product. The problem was that the site had a pirated (nulled) copy downloaded from a third-party site, so it never got updates.

LiteSpeed Cache versions before 5.7.0.1 had a vulnerability, CVE-2023-40000, that let an unauthenticated attacker inject JavaScript into admin pages. The developers fixed it in October 2023. In spring 2024 a mass attack began on sites that hadn’t updated: the script created a new administrator (specifically wp-configuser or wpsupp-user) and added malicious code to the site’s files. WPScan researchers reported on this campaign in May 2024.

So the site wasn’t hacked because of WordPress itself or because of LiteSpeed Cache. It was hacked because the plugin copy was pirated and stuck on an old version. The official plugin had received the fix six months before the attack.

Why Google Ads blocks accounts for this

Google checks not only the ads but also the site they lead to. A page that sends visitors to other sites through hacked code falls under the Google Ads policy on abusing the ad network. To the site owner this feels unfair, since they are the victim. To Google, though, it’s a site that harms users, and the ads won’t run while the code is there.

The same goes for Search: a hidden redirect that shows people something different from what Google sees violates Google’s spam policies, and Google flags hacked sites in the Security Issues report in Search Console.

What we did

• Restored the site from a clean backup and moved it to a new server.
• Removed the malicious code and the rogue administrator.
• Removed the nulled plugins. During the review we found another 18 spots in plugins that could serve as backdoors (hidden ways back in for a repeat hack).
• Added protection against a repeat hack and gave the client a report on the work done.

Why the client moved off WordPress

After the cleanup the site worked, but the risk remained: the theme and some plugins came from unofficial sources, and any update or new vulnerability could repeat the story. Paid licenses, constant updates and vetting every plugin mean ongoing costs and ongoing headaches for a business that just wants to take bookings.

Within a month the client decided to move to our Atom content management system: a one-time payment for development, no third-party plugins and no licenses to renew. We built a new turnkey site; the result is in our portfolio.

As of November 2026 the client is on ongoing maintenance with us. We are currently building a turnkey CRM system for them and preparing the site to start SEO promotion.

How to check whether your site has been hacked

• Open the site the way a new customer would: on a smartphone, on mobile data, in incognito mode. Checking from your work computer won’t show anything.
• Review the list of administrators in the admin panel. An account you don’t recognize is a sure sign of a hack.
• Check the Security Issues report in Google Search Console and the site’s status in Google Safe Browsing.
• Don’t install nulled themes or plugins. They can’t be updated, and some ship with backdoors already in place.
• Keep backups off your main server. In this case, the copy on the old server is what let us pinpoint the changed files.

If your ads suddenly get disapproved for a “compromised site” or customers complain about strange redirects, get in touch. We handle investigation and cleanup as part of our website maintenance service.