Fixing “Ghost” Admins & Fatal Errors in WordPress Posts After a Hack

I’ve cleaned over 4,500 hacked WordPress websites, and I usually see the same patterns. In fact, of the 700+ sites I recovered last year, 70% were compromised by simple fake hidden plugins. But every once in a while, I encounter a piece of malware that uses brilliant database manipulation to hide its tracks.

Recently, a client’s site was hit with a highly sophisticated database exploit. It caused two major issues: thousands of invisible “ghost” administrators, and a fatal error that completely broke the Posts dashboard. Standard security plugins and automated malware scanners completely missed it.

Here is a deep dive into how this zero-ID database exploit works, why your PHP error logs won’t catch it, and exactly how to clean it up permanently.

Part 1: The “Ghost” Admin Users Exploit

Normally, when a hacker creates a rogue admin account, it is easy to spot and delete. To avoid quick detection, this malware didn’t just hide the users—it broke the WordPress UI rendering.

The dashboard tallied 3,364 administrators, but the user list looked like this: just empty checkboxes and blank space.

My first instinct was to look for a malicious PHP script using the pre_get_users hook to filter out the names. However, after neutralizing the plugins and running a custom PHP scanner, the code was completely clean. The issue was buried in the database itself.

The Discovery: Duplicating the Zero ID

When I opened phpMyAdmin and inspected the wp_users table (using the site’s custom U0CHCi3_ prefix), the root cause was obvious:

Every single malicious account had an ID of 0.

In WordPress core architecture, an ID of 0 is strictly reserved to represent an “unauthenticated visitor.” When WordPress loops through the user list to build the dashboard, it calls the get_userdata() function for each ID. Because WordPress is hardcoded to fail when queried for an ID of 0, it can’t fetch the username or email. The dashboard draws the table rows based on the total count, but fails to render any text inside them.

To achieve this, the malware stripped the PRIMARY KEY and AUTO_INCREMENT constraints from the wp_users table, allowing it to inject thousands of duplicate zeros.

How to Fix the Hidden Users

Because the malware used a highly specific ID, we can safely wipe these rogue accounts using phpMyAdmin without touching the legitimate admins.

Note: Always back up your database before running custom SQL queries. Ensure you change the custom U0CHCi3_ prefix in these snippets to match your own database (usually wp_).

1. Delete the Malicious Users: Run this command in the SQL tab to destroy every account sharing the zero ID.

DELETE FROM U0CHCi3_users WHERE ID = 0;

2. Clean the Orphaned Metadata: Sweep up their leftover permissions so the dashboard counter resets.

DELETE FROM U0CHCi3_usermeta WHERE user_id = 0;

3. Repair the Database Structure: You must restore the Primary Key constraints, or the database will break the next time a real user registers.

ALTER TABLE U0CHCi3_users ADD PRIMARY KEY (ID);
ALTER TABLE U0CHCi3_users MODIFY ID bigint(20) unsigned NOT NULL AUTO_INCREMENT;

Once executed, the ghost accounts are purged, and the WordPress dashboard immediately returns to normal.

Part 2: The Crashing Posts Page

After fixing the users, I noticed a secondary symptom. Navigating to the Posts dashboard resulted in a critical error rendering directly inside the first row of the table. The other 245 posts were completely missing.

This happens because the edit.php loop successfully queries the total post count, but when it begins drawing the rows, it hits corrupted data, throws a fatal PHP error, and dies instantly.

The Discovery: Casino Spam on ID 0

I went back into phpMyAdmin, this time looking at the U0CHCi3_posts table. I ran a query to find any posts assigned to an ID of 0. The result was a massive list of Casino SEO spam:

The malware had executed the exact same schema exploit here. It removed the primary key constraints from the posts table and injected hundreds of spam posts with ID = 0. When the WordPress backend tried to load a post object with an ID of 0, the core functions failed to instantiate it, crashing the loop.

How to Fix the Corrupted Posts Table

Because 0 is never a valid post ID, we can safely delete all of this SEO spam and restore the database constraints without harming real content.

1. Delete the Spam Posts and Orphaned Meta:

DELETE FROM U0CHCi3_posts WHERE ID = 0;
DELETE FROM U0CHCi3_postmeta WHERE post_id = 0;

2. Repair the Posts Table Structure:

ALTER TABLE U0CHCi3_posts ADD PRIMARY KEY (ID);
ALTER TABLE U0CHCi3_posts MODIFY ID bigint(20) unsigned NOT NULL AUTO_INCREMENT;

3. Reassign Valid Orphaned Content: If you notice valid items (like wp_navigation) that were assigned to the deleted zero-ID author, reassign them to your main admin ID (e.g., ID 1) to prevent theme rendering errors:

UPDATE U0CHCi3_posts SET post_author = 1 WHERE post_author = 0;

Final Thoughts

This case study is a perfect example of why relying purely on automated malware scanners isn’t enough. Plugins scan files, but they rarely look for missing database constraints or null-ID logic bombs. If your WordPress site is experiencing bizarre UI glitches, blank rows, or localized fatal errors after a hack, the database structure itself has likely been compromised.

Is your WordPress site acting strangely, or are you seeing phantom users in your dashboard? Get in touch and I can help you perform a deep forensic audit to secure your server.