Hidden Admin in WordPress: How to Find an Invisible Attacker

A client sent me a message:

“Could you take a look at my website, please? Wordfence sent me an alert that a file called wp-fixplugin.php changed on the site. Isn't that name a bit suspicious?”

Damn right it is.

Published: 28 Aug 2026

I got to work and cleaned the site up in 3 hours. While cleaning, I took notes so I could later go through the backups and try to figure out how the site got compromised.

I'm not a forensic analyst, so based on my own knowledge and abilities I put together a simple timeline of the attack:

The dates line up with a security hole discovered a few days earlier (first row of the table). It was a serious vulnerability in the WordPress core - the type where the attacker doesn't need to know any password at all, breaking in directly through a bug in the software (so-called RCE, remote code execution). The site was wide open to it at the time. The window between the patch being released and the client's update is exactly when the attacker first struck.

Now, in more detail, about what was actually happening on the site.

The suspicious wp-fixplugin.php file in MU plugins, and a fake Google Tag Manager

MU plugins have a special place in WP. They're pieces of code that run before regular plugins, and they're not visible in the WP admin.

One of them, named wp-fixplugin.php (the one Wordfence flagged, as the client wrote) was injecting code (JavaScript) into the page that tried to pass itself off as Google Tag Manager.

Funny thing is, this site actually uses cookieless analytics from Koko (more about it in the article Do You Track Your Website Traffic? I Tested Four Tools at Once - Here Are the Results). On top of that, in the code it was communicating with a completely different server than Google's.

And it was done cleverly - it only injected itself into pages for visitors, not for logged-in admins, so nobody who owns the site would ever see it with their own eyes.

It also had its own remote API letting the attacker edit the JavaScript content, or delete the whole backdoor outright. In other words: the attacker kept a service hatch into their own malware so they could update it. Sneaky!

It turned out the infection was present in backups going back three weeks. Rolling the site back a month is a lot for a site with a blog and various courses. I decided it would be simpler to clean the site than to painstakingly search through content changes (and reopen it to the vulnerability all over again).

The unknown administrator

It occurred to me to check whether the site was infected by the backdoor from Jul 17. It's known to first show up by creating a foreign admin account. And sure enough, it was there - named, so there'd be no doubt: wpenginebot.

I deleted it, and within a minute the account reappeared. In Wordfence's login history I found the dates of the account's last successful logins. According to the IP address, the bot was connecting from Frankfurt (which of course doesn't necessarily mean anything - could be a VPN).

Normally I start by changing passwords (database, FTP, WordPress). Here I only changed FTP and the database - the attacker (doesn't matter whether human or bot) was logging in through an admin account it had created itself, and which it could even restore automatically.

Checking the WP configuration file wp-config.php

In the WP configuration (the wp-config.php file) lines had been added allowing code execution from the /wp-content/uploads folder - that's the folder where images and media are stored, and it has no business running code. The moment something like that shows up on a site, something is going on (even if no other traces were left).

A plugin that optimised absolutely nothing

Among the installed plugins I found one with an innocent-sounding name - "WordPress Cache Optimizer". First, I didn't recognise it, and second, its version number seemed odd: 1.0.0. I suspected it might be some abandoned plugin. But no.

That "cache optimizer" wasn't optimising anything at all. What it did optimise was adding yet another hidden admin account, wphiddenbot, in a way that kept it out of the admin panel. Opening up the database confirmed it.

Good for a laugh

The password for that hidden admin account was written directly in the code. An attacker who went to all that trouble hiding it left the key for other crooks right under the doormat.

They also used a script that called itself "Site Health Cleanup". In reality it checked the list of admins - probably precisely so it could restore admin accounts after they were deleted.

After deleting the intruder's account from the admin panel and the second (hidden) one from the database, the account never came back.

Recap of deleted files

Let's recap. The plugins and files with the infection were:

• wp-content/mu-plugins/wp-fixplugin.php
• wp-content/plugins/wp-content-filter/
• wp-content/plugins/wordpress-cache-optimizer
• an edit inside wp-config.php
• + possibly more in the WP core (see the cleanup section below).

Cleanup

The cleanup looked like this:

• Regenerating the "salts" - replacing the security keys (salt keys) in wp-config.php, so that any stolen login cookies would stop working for the attacker.
• Setting new passwords for every access point (database, FTP; in other cases I'd also regenerate the WP accounts, when it's not clear how the attacker got in).
• A complete re-upload of the WordPress core with a clean version (naturally excluding htaccess and wp-config).
• Searching wp-content/uploads for any executable code.
• A full site scan with a plugin (Wordfence - how to set it up in this article) to confirm nothing malicious was left.

Frequently Asked Questions