Updated 28 September 2026. This article went out on 1 September as “Poor Passwords Are the Attack Vector, Not WordPress”. It rests on one incident, and I wrote it as a password story. On a second read of the same incident, the password is the one entry point I had to infer. The four others were found on the server. The article has been rewritten around that count; the password advice is still here, lower down the list.
The Incident
A media company noticed something wrong when Chinese-language pages started appearing in Google’s results, indexed under their own domain. Visitors to the site saw nothing unusual. The pages had been injected at some point in the past without triggering an alert.
The client emailed: “Have we been hacked?”
A first remote look showed nothing in the WordPress admin. I changed the admin password straight away, as a first response.
The deeper review of the server found the rest:
- rogue files
- an administrator account nobody had created
- a file manager left behind by a third-party developer
- a copy of phpMyAdmin reachable from the public internet
- two old copies of WordPress in subdirectories, left over from a previous migration
The site was restored from backup and Sucuri cleaned what remained. Every password was reset, every admin account was reviewed, and the tools and old installs were removed.
Why It Became a Password Story
My assessment to the client was “if it is really hacked, then it was the password.” The admin password had been shared with a development contractor, and the account had no two-factor authentication. On the evidence available, it was the most probable entry point, and it became the headline of this article.
Now count what was on that server. A shared credential. A backdoor admin account, found on the backup, which makes it the attacker’s way back in. A file manager. A public database console. Two WordPress installs nobody maintained. Five ways in, or back in. The password is the one that was inferred rather than found, and a fix that stopped at the password would have left the other four in place.
What the Other Four Have in Common
None of the four had an owner, so no update cycle, cleanup checklist or account review reached them.
Unowned installs get no updates. The two old WordPress copies had no owner after the migration, so they sat outside every update cycle. Any core or plugin flaw published after they were abandoned stays open on them, and they answer web requests on the same domain as the live site.
Leftover tools outlive the build. The file manager and phpMyAdmin are server management tools left in place after the build because nobody had a cleanup checklist, and most hosting control panels ship them as standard. Automated scanners request /phpmyadmin on every site they find.
Backdoor accounts survive a password change. The rogue administrator had its own credentials. Resetting the original admin password did nothing to it. Only a review of every admin account against a list of real people found it.
The Checklist, in the Order I Would Run It Now
1. Inventory everything on the server that answers a web request. Every WordPress install, every subdirectory, every admin tool, every file a migration left behind. For each one, name the person who owns it.
2. Remove what has no owner. Old installs, staging copies in subdirectories, web file managers, database consoles. File and database access belongs on SSH and SFTP, where it is authenticated, logged, and not reachable from the public web.
3. Review every administrator account. Open the Users screen, filter by Administrator, and ask of each account whether that person still works on this site. Name accounts after people, never after roles: “developer” could be anyone from any project, while “Sarah” is a thirty-second decision. If a developer needs access, create a separate account with the minimum role and delete it when the project ends.
4. Then the passwords. A unique, random password for every admin account, kept in a password manager. Two-factor authentication enforced on every admin account through a plugin, since WordPress does not require it by default. Change any account still called “admin”; WP-CLI does it in one command. Rate-limit login attempts at the plugin or server level.
What This Looks Like When We Take Over a Site
When we take over hosting for a site, the baseline covers all four steps: what is on the server, who owns each piece, which admin accounts match a real person, and the password and two-factor settings. Server tools and old installs without an owner are removed, not documented. On a typical site this takes about two hours.
The Free Site Audit
If you do not know what else is running on your server besides the site you look at every day, we offer a free site audit at managedhosting.partners. You get a list of everything on the server that answers a web request, who appears to own it, and which admin accounts no longer match a real person.
