A media company in Australia noticed something wrong when Chinese-language content started appearing in their Google search results.
Not on their site. In Google’s index. Pages they’d never created, indexed under their domain, visible to anyone searching their company name. The site looked normal when you visited it. But Google had been crawling something else entirely — content injected quietly into their WordPress installation at some point in the past, without triggering any alert, without anyone noticing.
The client emailed in a panic. “Have we been hacked?”
I looked through everything I could access remotely. Nothing visible in the WordPress admin. The site looked clean. But the search results don’t lie. I changed the admin password immediately, as a first response.
A day later, when I did a deeper review: rogue files on the server, a rogue administrator account that nobody had created, a file manager left behind by a third-party developer, a copy of phpMyAdmin accessible from the web, two copies of an old WordPress installation sitting in subdirectories from a previous migration. Entry points everywhere.
My assessment to the client was direct: “If it is really hacked, then it was the password.”
Not a WordPress vulnerability. Not a plugin zero-day. A shared admin password — given to a development contractor who had finished their work and moved on, with no revocation process, no two-factor authentication, and server management tools left accessible that nobody had thought to remove.
The site was restored from a six-hourly backup. Sucuri cleaned what remained. We reset every password, reviewed every admin account, and removed everything that shouldn’t have been there.
This is what a WordPress hack actually looks like, when you get under the bonnet.
The Myth That Won’t Die
“WordPress is insecure” is one of the most persistent and most misleading narratives in web hosting.
I understand where it comes from. WordPress powers over 43% of websites on the internet. A platform that ubiquitous is a target. Automated scanning tools probe WordPress login pages millions of times per day because the volume makes it worth running. And when a WordPress site gets hacked — which does happen, and is genuinely disruptive when it does — the instinctive conclusion is that the platform itself is the problem.
But there’s a meaningful difference between “WordPress is a popular target” and “WordPress is insecure.” The same logic that blames WordPress would blame door locks for burglaries.
Here’s what the data actually shows.
Wordfence, which operates one of the largest WordPress security networks on the internet, blocks over six billion brute force attack attempts per month across its network. Six billion. The overwhelming majority of these attacks are credential attacks — automated tools testing common username and password combinations against WordPress login pages. Admin/admin. Admin/password. The site’s own domain name as the password. Credentials leaked from other breaches, now being tested everywhere the same email address was used to register.
Sucuri’s annual website threat research consistently finds “compromised credentials” as the leading category of compromise vectors — ahead of plugin vulnerabilities, ahead of outdated WordPress core, ahead of everything else.
Patchstack’s 2024 vulnerability report found that 97% of reported WordPress vulnerabilities came from plugins, not core. That’s cited everywhere, usually to support the narrative that WordPress plugins are a security disaster. It’s worth reading more carefully. Most plugin vulnerabilities require authenticated access to exploit — meaning the attacker already needs a valid username and password to use them. A credential compromise gets you in first. Plugin vulnerabilities are often the escalation path, not the entry point.
The platform is not the problem.
What Actually Happens Under the Bonnet
When I take over hosting for a site that’s been compromised, or when I do a security review on a site that hasn’t been hacked yet, I see the same patterns.
The default username. WordPress used to default to “admin” as the administrator username. The change was made years ago — you’re now prompted to choose a username during installation — but the number of live production sites still running with “admin” as their primary admin account is remarkable. An automated brute force tool that already knows the username is doing half the work before it starts.
The reused password. HaveIBeenPwned has catalogued over 14 billion compromised accounts from data breaches across the internet. The probability that a small business owner, their web developer, or their social media manager has at least one set of credentials in circulation from an unrelated breach is not low. And passwords get reused. Not because people are careless — because managing dozens of unique, strong passwords without a password manager is genuinely difficult, so people don’t.
The shared credential. A developer builds your site. You give them admin access. The project ends. The account stays. Six months later, that developer uses the same password on a client portal that gets breached. Now that credential is in a database somewhere, being tested against every WordPress login page an automated tool can find. The developer hasn’t worked on your site in six months. They don’t even know this is happening.
The no-MFA reality. Two-factor authentication adoption among WordPress sites is low. Not because people don’t know what 2FA is — most do. But because WordPress doesn’t enforce it by default, enabling it requires a deliberate decision, and on most shared hosting setups it’s an optional plugin rather than a platform requirement. The result is that a significant majority of WordPress admin accounts remain protected only by a username and password — which is one data breach away from being an open door.
The leftover tools. The media company incident had phpMyAdmin and a file manager accessible from the web, left over from a developer who needed them during the build. These are not WordPress vulnerabilities. They’re server management tools left in place because nobody had a cleanup checklist. They’re common. Most hosting migrations leave something behind.
None of this is exotic. None of it requires technical sophistication to exploit. Automated tools do it at scale, testing thousands of sites per hour, because the volume makes it economically rational even at low success rates.
Why the Industry Tells the Wrong Story
Here’s the uncomfortable part: the “WordPress is insecure” narrative benefits the people selling the solution.
Security plugins are a meaningful revenue category. Managed security add-ons — firewall services, malware scanning, real-time threat monitoring — are sold as premium tiers on top of hosting plans. When the story is “your platform is fundamentally vulnerable,” the answer is a product you can buy.
When the story is “your admin password is ‘welcome123’ and you haven’t reviewed your user list in three years,” the answer is a conversation about credential hygiene. That conversation doesn’t have a price tag. It’s harder to sell.
I’m not saying security plugins have no value. Wordfence, in blocking six billion attacks per month, is clearly doing useful work. Rate limiting on login pages, monitoring for changed files, alerting on new admin account creation — these are legitimate tools.
But they’re not a substitute for the basics. A firewall in front of a login page that accepts “admin” as a username is a harder obstacle, not a solved problem. The motivated attacker, or more accurately the automated credential-stuffing tool, has all the time in the world.
The hosting industry has a structural incentive to sell you server-level security products rather than discuss operational practices. I have the opposite incentive: the fewer incidents on sites I manage, the less time I spend on emergency responses and the more time I spend on everything else.
A Charity That Didn’t Have to Lose Three Days
A New Zealand health charity — a nationally recognised organisation running donation campaigns and event registrations — had their site compromised and taken offline by their own hosting provider. The host quarantined it rather than clean it. The site was down while the charity scrambled to find someone to help.
When I took over the migration, the site had been cleaned by Sucuri as a precondition. It came over to managed hosting with SSL, proper backup configuration, and the kind of hardening that should have been standard from the start.
The original attack vector was never formally diagnosed, but the pattern is familiar: a charity on budget shared hosting, no monitoring, no 2FA enforced, no dedicated technical support. Probably a credential issue, possibly exacerbated by outdated software. The kind of thing that doesn’t get caught until it’s already a problem.
The cost wasn’t just remediation. It was days of downtime for a site that ran public health information and donation processing. It was the operational cost of an emergency that didn’t have to be one.
The fix isn’t complicated. It’s not expensive. It’s a checklist.
The Credential Hygiene Checklist
I’ll say what the security marketing industry won’t, because it doesn’t have a product to sell you at the end of it.
The single most impactful thing most WordPress site owners can do for their security posture costs nothing.
Change “admin” to anything else. If your primary administrator account username is still “admin,” change it. Right now. This is not a complicated fix — WP-CLI does it in one command. It removes the most commonly guessed username from every brute force attempt immediately.
Name accounts after people, not roles. Every username should be the identifiable first name of an actual person — never “developer,” “agency,” “marketing,” or “webmaster.” A role name tells you nothing when you review the user list in two years: “developer” could be anyone from any project, and deciding whether that credential should still exist becomes an archaeology exercise. “Sarah” is a thirty-second decision — either Sarah still works on this site or she doesn’t. A generic account also invites sharing, because a login that belongs to nobody in particular ends up belonging to everybody who ever worked on the site.
Use a unique, strong password for every admin account. Not “welcome123.” Not the site’s domain name. Not a variation of a password you use for other services. A random 20-character string that exists nowhere else. A password manager makes this trivial. LastPass, 1Password, Bitwarden — any of them. The argument that managing multiple unique passwords is too inconvenient stopped being valid when password managers became free.
Enable two-factor authentication. On every admin account. Not as an optional feature — as a requirement. WordPress doesn’t enforce this natively, but a security plugin (WP 2FA, Wordfence’s built-in 2FA, Google Authenticator) can enforce it across all accounts. The extra fifteen seconds of login friction is not the issue. The issue is that it makes credential stuffing attacks functionally useless — even if the attacker has your correct username and password, they can’t get past the second factor.
Review your admin accounts. Open your WordPress Users screen and look at everyone with Administrator role. Ask, for each one: does this person still need admin access? Is this person still associated with this site in any way? If the answer to either question is no, delete the account. Former developers, contractors who finished a project, agency accounts from a build that happened three years ago — they all accumulate. Each is an attack surface.
Don’t share passwords. If a developer needs access, create them a separate account with the minimum required role. When the project ends, delete it. This is not complicated to manage. It’s discipline.
Remove tools that don’t belong on a production site. File managers, phpMyAdmin, old installation files, staging copies of the site in subdirectories — anything that shouldn’t be accessible on the live server should not be there. A managed hosting provider should catch this as part of migration review. On shared hosting, it’s your responsibility.
None of this requires a paid product. All of it is accessible to anyone managing a WordPress site.
The Platform Is Fine
WordPress core has had remarkably few critical security vulnerabilities over the past several years. The core team maintains an active security release process — vulnerabilities get patched quickly, and major releases are thoroughly reviewed. The “WordPress is insecure” narrative relies on conflating plugin vulnerabilities (97% of reported issues, most requiring authenticated access) with core security.
Meanwhile, the platform that “everyone knows is more secure” — because it’s proprietary, or newer, or less ubiquitous — is just as vulnerable to credential attacks. The login page is the login page. An admin account with a weak password is an admin account with a weak password. The platform doesn’t change the math on that.
What changes the math is: unique passwords, two-factor authentication, regular review of who has access to what.
This is not a product you can buy. It’s an operational practice. The hosting industry prefers the former because it has a price. I prefer the latter because it actually works.
What I Actually Check on a New Site
When I take over hosting for a site, before anything else, there’s a security baseline I want to see.
No “admin” username. Changed immediately if present.
Strong, unique passwords on all admin accounts. Changed and confirmed. Sent via a secure channel, not email.
2FA enabled on all admin accounts. Configured, tested, confirmed working.
Admin account list reviewed. Former developers, contractors, agency accounts — anything that doesn’t have a current reason to exist gets removed.
Login attempt rate limiting in place. Either through a plugin or at the server level. Slows brute force tools significantly.
Server-level tools removed. phpMyAdmin, web file managers, old installation directories — removed, not documented. There is no good reason for a database console to be reachable from the public internet in 2026. Part of the problem is education: most hosting control panels ship these tools as standard, so a generation of site owners and developers learned that this is how you work on a site. It is not. File and database access belongs on SSH and SFTP — properly authenticated, logged, and invisible to the automated scanners that probe every site on the internet for /phpmyadmin as a matter of routine.
This takes about two hours on a new site. The ongoing maintenance is minimal. And it eliminates the most common attack vector in WordPress hosting.
No product required. Just the checklist.
The Free Security Audit
If you’re reading this and you’re not sure what your WordPress security posture looks like — if you don’t know whether “admin” is still a username on your site, if you haven’t checked your user list in a year, if 2FA is “on the list” rather than configured — we offer a free site audit at managedhosting.partners.
No obligation, no sales pitch. A clear view of where your site stands against the credential hygiene checklist, what’s missing, and what it would take to fix it.
Do it once. Do it right.
