The Plugin the Owner Never Saw: How Hidden WordPress Malware Ran for Months on Two Sites We Cleaned Up

01 / 07

What does hidden WordPress malware look like when the owner cannot see it?

From the owner's side, it looks like nothing. The site loads, the dashboard looks normal and the Plugins screen lists only plugins the owner recognizes. Fake plugins are built for exactly that: in one study of 20 common samples, 19 removed themselves from the WordPress plugin list, and they often pose as performance or caching tools (Imunify360, 2026).

Most owners picture a hacked website as a defaced home page or a red warning in Chrome. The kind of compromise this article is about is the opposite. It is designed to leave the site looking and working exactly as before, so the owner has no reason to look.

Security researchers keep finding the same design. Wordfence described a fake plugin, posing as an anti-malware tool, that hides itself from the plugins page, keeps the attacker's access and injects JavaScript into the site's header (Wordfence, 2025). Imunify360 analyzed 20 fake plugins and found that they "disguise themselves as performance tools, WooCommerce extensions, security helpers, and caching engines" (Imunify360, 2026).

The same study found one family that injects JavaScript only for "visitors who aren't logged in to WordPress" (Imunify360, 2026). That one detail explains why owners miss it. The owner is almost always logged in when looking at their own site.

Google treats this kind of thing as hacked content. Its spam policies name code injection, page injection, content injection and redirects as forms of it, and say hacked content "can potentially install malicious content" on visitors' machines (Google Search Central, 2026).

02 / 07

What did we find on the two sites?

We found the same fake caching plugin on two client sites, months apart: a professional services firm in July 2026 and a real estate brokerage in October 2026. On both, the plugin's files dated to November 29, 2025. It hid from the Plugins screen, skipped logged-in users and served visitors JavaScript fetched from a server the attacker controlled.

We are not naming either business. They are clients, and the lesson is about the attack, not about them. Both ran ordinary WordPress sites with ordinary plugins.

The first site, a professional services firm, was found on July 2, 2026, during our own review of the site. A plugin presented itself as a cache engine, with a made-up author name. It was not on the Plugins screen. It ran a script for every visitor who was not logged in and was not a bot, and that script asked the site's own server for more code, which the server fetched from the attacker's machine and handed back to the visitor's browser.

The second site, a real estate brokerage, was found on October 3, 2026, and nobody was looking for malware at the time. The site had gone down because a page builder plugin updated itself and its paid add-on, with a lapsed license, stopped working. While we were fixing that, the integrity check in the RankShield plugin on the site reported four critical findings. It was the same fake cache plugin, with the same file date and the same empty leftover folder beside it.

Two sites, one plant date, and both sites in the same hosting account family. That pattern points away from one unlucky website and toward something shared, such as a login or an account that reached both. We could not prove which. Server logs from November 2025 had long since rotated away, so the way in is honestly unknown on both sites.

03 / 07

How did the plugin stay hidden for months?

It used three ordinary WordPress features against the owner. It filtered itself out of the Plugins screen, it served its script only to logged-out visitors who were not bots, and it kept its real payload on the attacker's server rather than on the site. Nothing on the site changed day to day, so nothing on the site looked wrong.

The first trick is built into WordPress. The Plugins screen gets its list through a filter, all_plugins, which "filters the full array of plugins to list in the Plugins list table" (WordPress all_plugins reference, 2026). Any plugin can hook into that filter. A legitimate one might use it to rename itself for a client. A malicious one uses it to delete its own row, so the screen shows every plugin except the one that matters. Wordfence published a sample doing exactly this, with the result that "the malicious plugin would not show up in the plugins list" (Wordfence, 2025).

The second trick is who sees the script. Logged-in users were skipped, so the owner, the office manager and the web developer, all of whom are usually logged in, saw a clean page. Bots were skipped too, which most likely kept the script away from Google's crawler as well.

The third trick is the one that matters most. The plugin did not carry its attack inside it. It carried a way to fetch one. Each time it ran, it asked the attacker's server what to deliver and passed that along. On a quiet day that could be nothing at all. On another day it could be ad injection, a redirect or a fake login prompt. The site's files stayed the same either way.

That is why this kind of code can feel dormant and then suddenly not be. It is not asleep on a timer. It is waiting for instructions, and the attacker can change what it does at any time without touching the site again. We do not know what it delivered to each visitor on each day, and neither would any owner. That is the point of building it this way.

04 / 07

Why did Google and the usual checks not raise the alarm?

Each common check looks somewhere the malware was not. The Plugins screen was filtered, the owner's logged-in view was clean, Google's crawler was most likely skipped, and file checks against WordPress.org cover core and free plugins but not every file. Google itself says its Security issues report lists a sample of affected pages, "not necessarily complete" (Google Search Console Help, 2026).

Search Console is still worth reading, and Google calls the Security issues report the source of truth for what Google has found. But it can only report what Google sees, and Google warns that hackers "might hide the spammy content using cloaking techniques to avoid detection by site owners" (Google Search Console Help, 2026). A script that skips bots is built to stay off that report.

Checksum tools have a blind spot of their own. WP-CLI's core command "verifies WordPress files against WordPress.org's checksums" (WP-CLI core checksums, 2026), and its plugin command does the same for plugin files (WP-CLI plugin checksums, 2026). Both are excellent at catching a changed core file. But a whole extra plugin folder is not a changed core file, and a paid plugin has no WordPress.org checksum to compare against.

Security plugins can be targeted too. Imunify360 found that one fake plugin family scans for security tools and deletes them from the server, using file operations that "bypass WordPress entirely" (Imunify360, 2026). A scanner that runs inside WordPress is inspecting the same system the attacker already controls.

None of this means those checks are useless. It means no single one of them is proof. On the second site, what caught the plugin was a check built for this exact pattern: it compares the full list of plugins on the server with the list WordPress is willing to show. When the two lists disagree, something is hiding.

05 / 07

How did we clean it up and prove it was gone?

We moved the plugin out of the public web folder rather than deleting it, so the evidence survived, then cleared every cache that could still serve the injected script. We then proved the result: core files matched WordPress.org, a full scan of plugin and theme code found no second backdoor, and every page in the sitemap was checked logged out.

Containment came first. On both sites the plugin folder was moved outside the public web folder, where it cannot run, and kept as evidence. Deleting it would have been faster, and it would also have destroyed the only record of what it did.

Caches came next, because a cache can keep serving malware after the source is gone. On the first site, 73 combined JavaScript files built by the host's caching system had picked up the injected code, and all of them were cleared with the rest of the cache.

Then we looked for a second way back in, because attackers rarely leave just one. On the first site, a deeper sweep found no other backdoor, web shell or persistence: no rogue scheduled tasks, no extra admin accounts, no altered server settings. On the second, all 1,315 WordPress core PHP files matched WordPress.org's checksums, and 13,104 plugin and theme PHP files were scanned with no real hits.

Finally, we checked the result the way a visitor would see it. On the second site, all 33 URLs in the sitemap were loaded logged out, without a cache-busting trick, and none served the injected code.

One honest limit remains. Because the way in was never established, cleaning the files does not close the door the attacker used. That is why the next steps matter as much as the cleanup.

06 / 07

How can you check your own WordPress site this week?

Compare the plugin folders on your server with your Plugins screen, check core and free plugins against WordPress.org, load your site logged out and read its source, and count admin accounts in the database. The self-check above walks through all eight steps. None of them needs special software, but a few need your host or developer.

Start with the check that caught this plugin. In your host's file manager, open wp-content/plugins and write down every folder. Then open the Plugins screen in WordPress. Every folder should have a matching row. Imunify360 puts it plainly: a plugin that exists in the filesystem but not in the admin panel is "a strong indicator of compromise" (Imunify360, 2026).

Next, check names. A folder called something like a cache engine, a performance helper or a session handler that you never installed deserves a closer look, especially if you already run a different caching plugin.

Then run the checksum commands, or ask your host to: wp core verify-checksums for WordPress itself and wp plugin verify-checksums --all for plugins from WordPress.org. Remember what they cannot cover: extra folders and paid plugins.

Then see your site as a stranger does. Log out, open a private window and load your home page and your contact page. View the page source and look for script tags pointing at domains you do not recognize. Because some malware only runs some of the time, one clean look is not proof, but a strange script is a clear answer.

Last, count your admins. Some fake plugins hide admin accounts from the Users screen, and one sample Imunify360 studied changes the database query so the Users screen "shows only the currently logged-in administrator" (Imunify360, 2026). Ask your host or developer to list administrator accounts straight from the database and compare.

If any of these checks turns something up, do not delete it on the spot. Take the site's files and database offline into a backup, then get help. If you want a second set of eyes on the site, start with our free SEO audit.

07 / 07

How do you stop it from coming back?

Close the likely doors and watch for the pattern. Turn on two-step login for every admin, change every password, remove plugins you do not use and keep the rest updated. Then add a check that compares what is on the server with what WordPress shows, because plugins carry 91% of new WordPress vulnerabilities (Patchstack, 2026).

Credentials come first. On the first site, our after-action review judged a stolen login the most likely way in, though it could not be proven, and WordPress's own hardening guide says "it's a good idea to enable two-step authentication as an additional security measure" (WordPress hardening guide, 2026). Turn it on for every admin, and change the passwords for WordPress, the hosting account, the database and any file manager or SFTP login. One weak login anywhere in that chain is enough.

Plugins come second. Patchstack counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025, with 91% in plugins and 9% in themes, and found that heavily targeted bugs were first exploited after a weighted median of 5 hours (Patchstack, 2026). The same WordPress guide says "if you are not using a specific plugin, delete it from the system" (WordPress hardening guide, 2026). Every plugin you remove is one less thing to patch on time.

Detection comes third, and it has to look at the server rather than the dashboard. RankShield, our founder's security company, added an integrity check to its WordPress plugin after the first of these two cleanups. It compares the plugins on the server with the plugins WordPress shows, looks for files that should not run from the uploads folder and scans for remote-controlled script injection. By default it reports and changes nothing; enforcement is a switch the owner turns on. It is the check that found the plugin on the second site. Details are on the RankShield WordPress plugin page. It is an option we offer, never a condition of working with us.

That second find is the reason we care about watching many sites at once. A pattern learned on one site, a fake plugin with a particular disguise and a particular way of hiding, became a check that caught the same plugin on another site three months later. One site's bad week turned into the next site's early warning.

For some sites the honest answer is to remove the attack surface instead. A business site that does not need WordPress can be rebuilt as a static site on Cloudflare web hosting, where there are no plugins to fake and no admin login to steal. Our guide to what moving off WordPress actually changes walks through when that trade is worth it.