WordPress website hacked through an outdated plugin: from detection to full recovery

If you run WordPress, security isn’t just a nice-to-have—it’s survival. Here’s why:

• Over 40% of all sites on the web are powered by WordPress (W3Techs.com stats). With that level of popularity, hackers see it as prime hunting ground.
• WordPress is open-source, meaning the core code is public. Great for developers, but it also means bad actors can study it to spot weak points. The WordPress core team patches things fast, but not every site owner keeps up.
• Then there’s the massive plugin and theme ecosystem—tens of thousands of add-ons built by third parties. It’s powerful but also risky: some plugins go unmaintained or ignore proper security practices, leaving big holes that admins might not notice right away.
• Long story short: skipping updates—core or plugins—can leave doors wide open.

In this post, we’ll walk through a real-world case we had to deal with: a WordPress site compromised because of an outdated plugin. From spotting the issue to cleaning it up, here’s how it went down—and what we learned.

Signs the Site Was Compromised

What tipped us off? Some very obvious red flags:

• Mobile users or logged-out visitors were redirected to shady spam or gambling sites.
• Google Search showed the warning: “This site may be hacked.”
• Strange URLs were indexed in Google that didn’t match legit content (a quick check via “site:domain.com” showed them).
• Some plugins just stopped working, and bits of their code looked tampered with.

Finding the Root Cause

A log and code audit pointed to one plugin: xyz-forms-lite (*name and file references changed for privacy).
It hadn’t seen an update in over three years and contained suspicious files like wp-fix.php and db1.php. On top of that, code using base64_decode() and eval() had been injected into functions.php—classic signs of a backdoor.

How We Handled It

Step 1: Take the Site Offline

We put the site into maintenance mode via .htaccess changes. Better to show a downtime page than risk serving malware.

Step 2: Back Everything Up

Before touching a single file, we backed up the whole system—code and database—so we’d have a clean snapshot for reference or forensic work later.

Step 3: Remove the Compromised Plugin & Malicious Code

The plugin was deleted completely. Then we searched for bad code:

grep -R “base64_decode” .
grep -R “eval(” .

Theme and plugin files were compared to clean vendor versions to catch anything that looked off.

Step 4: Reinstall WordPress Core & Plugins from Clean Sources

Fresh core install via CLI:

wp core download –force

Plugins were reinstalled only from trusted sources (wordpress.org) and only those that are actively maintained.

Step 5: Scan for Malware & Harden Security

Installed Wordfence to run a deep scan and clean up leftovers.
Enabled a Web Application Firewall and configured alert notifications.

Step 6: Update Everything

Every plugin was updated to its latest version. Custom theme and plugin code were also synced with the new WordPress core.

Step 7: Bring the Site Back & Request Google Review

If Google flagged your site or indexed junk URLs:

• Head to Google Search Console → Security & Manual Actions → request a review once you’re sure the site is clean.
• Use the Removals tool to purge bad URLs from search results.

Submitting URL removal requests in Google Search Console once the cleanup is done

Key Takeaways

– Don’t run unmaintained or flagged plugins.
– Back up your system regularly—it’s a lifesaver.
– Watch for code changes using tools like WP Activity Log or version control.
– Set up a security plugin (Wordfence is solid) and alerts for abnormal activity.
– Lock down admin access with CAPTCHA, IP rules, or two-factor auth.

Handy WordPress Tools/Plugins

WordPress security isn’t “set it and forget it.” It’s an ongoing routine—patching, scanning, and watching for signs of trouble.

Hopefully this breakdown helps other admins spot and handle similar risks before they turn serious.

Phung Huu Kien S-Chief