WordPress Redirect Hack: How a Fake Plugin Hide From My Dashboard and Hijacked Traffic

A client contacted me after discovering that his WordPress site was redirecting organic visitors to unrelated external pages. Revenue had already dropped. Trust was gone. But when he checked the dashboard, everything looked normal — no suspicious plugins, no obvious malware.

That is the hallmark of a fake plugin redirect hack. The malware does not just redirect traffic. It actively hides itself from the WordPress admin interface so the site owner never sees it.

After manual forensic analysis, I found a fake plugin directory in /wp-content/plugins/ that used WordPress hook manipulation to stay invisible and a remote API call to control redirect behavior dynamically. This post documents exactly how I identified, traced, and removed it.

If your site is redirecting right now, start with my free WordPress malware scan or go directly to my WordPress malware removal service.

Infection indicators at a glance

Why this redirect hack was invisible from the dashboard

The malware used WordPress’s own all_plugins filter to remove itself from the plugin list. This is the same filter WordPress uses internally to build the Plugins page. When the malware hooks into it and unsets its own entry, the plugin physically exists on disk but never appears in the admin interface.

Here is a simplified version of what I found in the fake plugin’s main file:

// Fake plugin hides itself from the WordPress Plugins page
add_filter('all_plugins', function($plugins) {
    unset($plugins['wp-performance-optimizer/wpo-main.php']);
    return $plugins;
});

That single hook is why the site owner checked the dashboard, saw nothing unusual, and assumed the problem was elsewhere. This is a well-documented technique that I have encountered in multiple cleanups, and it is the same approach used by known fake plugins like Zend Fonts WP, DebugMaster Pro, and the fake UpdraftPlus variants.

Some newer variants avoid the all_plugins filter entirely (because security tools now monitor it) and instead inject a CSS display:none rule on the plugin’s row in the admin HTML. The result is the same: the plugin is invisible to anyone browsing the dashboard.

I have documented many of these fake plugin names on my comprehensive list of fake and malicious WordPress plugins.

How the redirect worked without leaving a trace

In a basic redirect hack, you find the target URL hardcoded somewhere — in .htaccess, in a JavaScript file, or in the database. You search for the domain, find the line, and remove it.

This infection was different. The redirect URL was never stored on the site. Instead, the malware called out to an attacker-controlled server at runtime and received the redirect destination dynamically. The mechanism I observed was an HTTP request wrapped in WordPress’s own wp_remote_get() function, though I have also seen variants that use DNS TXT record lookups or base64-encoded cookie instructions to achieve the same result.

The practical effect: there was no malicious URL to grep for. The redirect destination could change daily without the attacker ever touching the infected site again.

The malware also skipped redirects for logged-in administrators and known search engine bots. That meant the site owner never experienced the redirect, Google’s crawler saw clean pages, and only real human visitors from organic search were hijacked.

If your redirect only affects some visitors or appears intermittently, that conditional logic is almost certainly why. I covered a similar pattern involving mobile-only targeting in my mobile redirect hack case study.

How I found the fake plugin via SSH

Since the dashboard was useless here, I connected via SSH and went straight to the filesystem. These are the exact commands I used to identify the infection.

Step 1: List plugin directories by modification date

ls -lt /path/to/wp-content/plugins/

Any plugin folder modified recently that you did not update yourself is a red flag. In this case, a directory named wp-performance-optimizer had been modified two days before the client noticed the redirect — but it had never been installed through the dashboard.

Step 2: Search for the all_plugins filter hook

grep -rl "all_plugins" /path/to/wp-content/plugins/

Legitimate plugins rarely hook into all_plugins. Any match outside of well-known security plugins is suspicious. This command returned a single file inside the fake plugin directory.

Step 3: Search for remote request functions in plugins

grep -rn "wp_remote_get\|wp_remote_post\|file_get_contents\|curl_exec\|dns_get_record" /path/to/wp-content/plugins/ --include="*.php"

This revealed the outbound call that was fetching redirect instructions from the remote server. The domain was obfuscated with string concatenation, but the function call itself was visible.

Step 4: Check for hidden admin users

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

In this case, there was a rogue administrator account created shortly after the infection date. It was hidden from the dashboard using a pre_user_query hook that excluded its username from all admin-facing queries — the same technique I described in my guide on finding hidden admin users in WordPress.

Step 5: Inspect mu-plugins for persistence

ls -la /path/to/wp-content/mu-plugins/

Some variants drop a loader file in the mu-plugins directory as a backup persistence mechanism. Must-use plugins auto-execute on every page load and are not listed in the standard Plugins page — making them another favorite hiding spot. In this cleanup, the mu-plugins directory was clean, but I always check it as standard procedure.

How the full infection chain worked

Putting the pieces together, the attack followed a clear sequence:

1. Initial access — the attacker exploited a vulnerability in an outdated plugin to gain file upload capability.
2. Fake plugin deployment — a fake plugin directory was created in /wp-content/plugins/ with a legitimate-looking header (plugin name, version, author URI) so it would blend in if anyone browsed the filesystem.
3. Dashboard hiding — the all_plugins filter was hooked to unset the fake plugin from the admin plugin list.
4. Hidden admin creation — a backdoor admin account was created and hidden from the Users page using pre_user_query manipulation.
5. Remote-controlled redirect — the redirect URL was fetched from an external server on every page load, with conditions to exclude admins and bots.
6. Credential harvesting — with admin access secured, the attacker could return at any time to re-infect, even after partial cleanup.

That is why deleting one file or deactivating one plugin was never going to fix this. Every layer of the infection needed to be identified and removed independently.

Complete removal steps

1. Identified and removed the fake plugin

I deleted the entire fake plugin directory after confirming it had no connection to any legitimate functionality on the site. The key validation: the plugin was not listed in WordPress.org’s repository, the header metadata was fabricated, and the code contained the hiding hook plus the outbound redirect call.

2. Removed the hidden admin account

The rogue administrator was removed via WP-CLI after verifying its creation date aligned with the infection timeline:

wp user delete <rogue_user_id> --reassign=1

3. Cleaned database persistence

I checked wp_options for any injected option rows that the malware used to store configuration data (API endpoints, cookie names, infection timestamps). I also inspected wp_posts for injected content, following the same process I describe in my WordPress database malware guide.

4. Scanned for related backdoors

Fake plugin malware rarely travels alone. I scanned the entire wp-content directory for webshells, obfuscated PHP files, and recently modified core files:

# Find PHP files modified in the last 14 days
find /path/to/wp-content/ -name "*.php" -mtime -14 -ls

# Search for common obfuscation patterns
grep -rl "base64_decode\|str_rot13\|gzinflate\|eval(" /path/to/wp-content/ --include="*.php"

For a deeper dive into identifying obfuscated malware, see my guide on obfuscated PHP malware detection in WordPress.

5. Hardened credentials and access

After confirming the infection was fully removed, I rotated all credentials: WordPress admin passwords, hosting panel password, database password, FTP/SFTP credentials, and WordPress security salts in wp-config.php. If you are not sure how to handle salts, my WordPress security hardening guide covers the process.

Why scanners missed this infection

Automated scanners compare files against known malware signatures and official WordPress repository checksums. This infection evaded detection for three reasons:

First, the fake plugin directory was not part of WordPress core, so there was no checksum to compare against. Second, the code was structured to look like a legitimate plugin — proper file headers, standard WordPress function calls, no obvious obfuscation in the main file. Third, the redirect URL was never stored locally, so signature-based scanners had no malicious domain to match.

This is the pattern I see repeatedly in the cleanups I do. Scanners are a useful first pass, but they are not a substitute for manual filesystem and database inspection. If your scanner says the site is clean but visitors are still being redirected, the malware is likely using one of these evasion techniques.

How to check your site right now

If you suspect a similar infection, here is a quick diagnostic you can run from SSH or your hosting file manager:

1. Count plugin folders on disk vs. dashboard — if the filesystem shows more plugin directories than your Plugins page lists, one of them may be hiding itself.
2. Search for the hiding hook — run grep -rl "all_plugins" wp-content/plugins/ and investigate any result that is not a known security plugin.
3. Check mu-plugins — any file in wp-content/mu-plugins/ that you did not place there is suspect.
4. Audit administrator accounts — run wp user list --role=administrator via WP-CLI, or query the database directly: SELECT * FROM wp_users INNER JOIN wp_usermeta ON wp_users.ID = wp_usermeta.user_id WHERE wp_usermeta.meta_value LIKE '%administrator%';
5. Test the site logged out — open the site in an incognito browser or from a different device. If it redirects only when you are logged out, the malware is excluding admin sessions.

Lessons from this cleanup

This case reinforced patterns I see across my 4,500+ WordPress cleanups. Dashboard visibility is not proof of safety. Scanners are a starting point, not a conclusion. And redirect malware in 2025–2026 is significantly more sophisticated than the simple .htaccess redirects that dominated a few years ago.

The most important lesson: if you cannot find the source of a redirect from the dashboard, that does not mean the infection is small. It usually means the opposite — the attacker invested effort in concealment, which signals a more persistent and layered compromise.

When to get expert help

You should consider professional cleanup if any of the following apply: the redirect affects only some visitors or appears intermittently, the infection returns after you remove it, you suspect hidden admin accounts or database injections, your scanner reports a clean site but the redirect persists, or your search traffic or revenue has already been impacted.

I have cleaned 4,500+ hacked WordPress sites, including hundreds of fake plugin infections exactly like this one. You can hire me directly for manual investigation, cleanup, and hardening. For a similar case involving plugin-level persistence with cloaking, see my WordPress cloaking malware removal case study.

Need help now? Start with a free malware scan, check my fake WordPress plugin list to see if you recognize any names, or hire me for direct cleanup.

FAQ

Can WordPress malware hide a plugin from the admin dashboard?

Yes. WordPress provides a filter called all_plugins that controls which plugins appear on the Plugins page. Malware hooks into this filter and unsets its own entry, so the fake plugin remains active and executing code on every page load while being completely invisible to the administrator. Some newer variants use CSS injection instead of the filter to achieve the same visual hiding with less chance of detection by security tools that monitor filter manipulation.

Why do WordPress redirect hacks only affect some visitors?

Most modern redirect malware uses conditional targeting. The code checks whether the visitor is a logged-in administrator, a search engine bot, or a regular user before deciding whether to trigger the redirect. Administrators and bots see the normal site, while organic visitors from Google get redirected. Some variants also target specific devices (mobile only), referrer sources, or geographic locations. This makes the infection much harder for site owners to notice because they are always logged in when checking.

How do I find a hidden plugin that does not appear in my WordPress dashboard?

Connect to your server via SSH or FTP and list the contents of /wp-content/plugins/. Compare the directories you see on disk against what appears in your WordPress Plugins page. Any directory on disk that does not show up in the dashboard may be hiding itself. You can also run grep -rl "all_plugins" wp-content/plugins/ to find any plugin that is hooking into the filter used to manipulate the plugin list. Check /wp-content/mu-plugins/ as well, since must-use plugins auto-execute without appearing in the standard plugin list.

Can a malware scanner detect fake plugin redirect malware?

Not always. Fake plugins are designed to mimic legitimate plugin structure — they include proper file headers, use standard WordPress functions, and avoid common obfuscation patterns that trigger signature-based scanners. If the redirect URL is fetched remotely instead of being hardcoded, there is no malicious domain in the files for the scanner to flag. Manual investigation of the filesystem, database, and user accounts is often necessary to find and confirm this type of infection.

What should I do first if my WordPress site is redirecting visitors but I cannot find the source?

Stop checking from the dashboard — if the malware is hiding itself, the dashboard will not help you. Instead, connect via SSH, list all plugin directories on disk, search for the all_plugins filter hook, audit your administrator accounts with WP-CLI, and test the site while logged out in an incognito window. If you find a plugin directory you did not install, do not just delete it — back up the site first, then investigate the full infection chain including database entries and hidden users before removing anything. If the infection is beyond your technical skill, get expert help before the damage compounds.

Last updated: June 2026 by MD Pabel, WordPress Security Specialist — 4,500+ hacked sites cleaned since 2017. Founder of 3Zero Digital.