We get asked about password policy more than almost anything else in a security review. Two-factor authentication, password managers, forced resets on a schedule. All reasonable questions. None of them determines how bad a breach gets once someone's in. That comes down to one thing: what the compromised account was allowed to do.
The Password Is Rarely the Real Vulnerability
Here's the scenario we see most often. A contributor account gets phished, or a plugin with a privilege-escalation flaw gives an attacker a foothold they shouldn't have. Either way, someone unauthorized is now logged in as a real user. The question that determines the outcome isn't how they got in. It's what that account could touch once they were there.
If the compromised account is a contributor with permission to write drafts, the damage stops at drafts. If it's an editor with plugin install rights it was never actually using, the attacker now has a path to arbitrary code execution on your server. Same breach. Wildly different outcome. The gap between those two scenarios has nothing to do with password strength.
2026 has made this concrete in a way that's hard to argue with. Patchstack recorded 11,334 new WordPress vulnerabilities in 2025, a 42% jump over the year before, and found that the weighted median time from disclosure to mass exploitation is five hours. Plugin privilege escalation flaws made up a meaningful share of the worst of those. In August, Wordfence disclosed a critical flaw in the Pods Custom Content Types and Fields plugin that let an unauthenticated attacker escalate straight to Administrator or overwrite any user's password, including the site owner's. Around the same time, a separate flaw in WPMU DEV's Dashboard plugin hit any site that hadn't yet connected to the WPMU DEV Hub, the plugin's default state right after install. An unauthenticated attacker could forge the plugin's request signature and use that opening to install a plugin, delete plugins and themes, or log in as an administrator via SSO.
Both started with a vulnerability that let an account reach further than it needed to, then used that reach to escalate. They're worth reading in full if you want the technical detail, and they're useful examples of the different types of WordPress vulnerabilities sorted into categories rather than treated as one undifferentiated pile of CVEs.
It's also worth being direct about why attackers care about this. Attackers don't break into a WordPress site to read your drafts. They want what an Administrator account can do: install a plugin, edit theme files, create new users, reach the database. An attacker probing a site is hunting for the most privileged account they can reach with the least effort, because that's the account that turns a foothold into control of the whole platform. Over-permissioned users are exactly what that search is looking for, and the more of them exist on a site, the faster that search succeeds.
What the Principle of Least Privilege Actually Means Here
Least privilege is an old idea, older than WordPress, older than the web. Give every account exactly the access it needs to do its job. Nothing more. It sounds obvious stated that way, and it is, which is probably why it gets skipped. WordPress ships with five default roles (Subscriber, Contributor, Author, Editor, Administrator) and most installations we inherit have somewhere between two and three roles actually in use, with everyone else defaulted up to whatever got the job done fastest at the time.
That's the pattern. Someone needed to update a plugin once, so they got bumped to Administrator instead of getting a scoped, temporary grant. A freelance writer needed to embed a video, so they got Editor instead of a custom role with just the capability they needed. Six months later, nobody remembers why half the user list has full admin rights, and every one of those accounts is now a viable entry point to the whole site.
This happens constantly. A site with eleven Administrator accounts isn't unusual: a few belong to people who left the organization months ago, one or two belong to an agency whose engagement wrapped long before anyone thought to pull their access. None of it shows up as a problem in a scan, because none of those accounts are themselves malicious or compromised. They just sit there, fully privileged and unmonitored, expanding the attack surface for no operational reason at all.
This is the part that surprises people who come from a general IT security background rather than a WordPress-specific one. WordPress roles aren't just about who can publish what. Certain capabilities, particularly the ability to edit theme and plugin files directly through the dashboard, are functionally equivalent to server-level code execution. An Administrator account isn't a content permission. It's infrastructure access wearing a content management interface.
How We Actually Implement This
Applying least privilege to a WordPress install isn't a one-time cleanup. It's a standing practice, and it looks different depending on the size of the editorial team and what the site actually does.
Start with an audit
Before writing any rule about who should have what access, we pull the actual user list and map every account to a real person doing a real, current job. Anyone who fails that test, a departed employee, a vendor whose contract ended, a test account nobody remembers creating, gets removed immediately.
Custom roles beat default roles for anything specific
WordPress's five built-in roles were designed for a general blogging use case, not how enterprise teams actually divide editorial and technical work. We build custom roles with capability-level granularity when the default set doesn't match reality. A content editor who needs to manage media but never touches plugins or themes shouldn't be an Administrator because that's the closest built-in option. They should have exactly the capabilities that match their job. It's one layer of the broader, plugin-isn't-enough approach we take to WordPress security generally, access control is a pillar, not a checkbox.
Separate publishing from platform administration
This split matters most on any site with more than a handful of contributors. The people writing and approving content should never need the same access as the people managing plugins, themes, and server-level configuration. Collapsing those two functions into one role is how a phished writer's account becomes a plugin installation vector.
Treat elevated access as temporary by default
Someone needing Administrator rights for a one-time task, a plugin migration, or a theme update, doesn't need to keep that access afterward. We build workflows around time-boxed elevation rather than permanent grants, so the number of standing full-access accounts stays as close to zero as the organization can operate with.
Turn off file editing from the dashboard entirely
WordPress lets any Administrator edit theme and plugin files directly in the browser by default. Most organizations have no operational reason to keep that capability enabled, and disabling it removes one of the most direct paths from a compromised admin account to code execution, regardless of how that account got compromised in the first place.
Log and alert on privilege changes
A role change or a new Administrator account should generate a notification somewhere a human actually sees it. Silent privilege escalation, whether it comes from a misconfigured plugin or an attacker who's already inside, is far more dangerous when nobody's watching for it than when it triggers an alert the same day.
Review on a schedule, not a memory
Access review has to be a recurring maintenance task, not something that happens only after an incident. As part of our ongoing WordPress Maintenance and Support work, we treat the user role audit the same way we treat plugin updates and vulnerability monitoring: routine, scheduled, and logged.
On one enterprise account, every plugin change goes through the client's internal application security team for review and approval, and access gets audited monthly, not whenever someone remembers to check. That's what least privilege looks like once it's actually enforced instead of just stated as a policy.
The Uncomfortable Part
None of this is complicated, just tedious. Auditing a user list, mapping roles to actual job functions, building custom capability sets instead of reaching for the nearest built-in role, that's not glamorous security work. It doesn't show up in a pitch deck the way "we run continuous vulnerability scanning" does. But it's the layer that determines whether a single compromised account is a contained inconvenience or a full site takeover.
That doesn't mean treating every scan result as a five-alarm fire, either. On our enterprise accounts, we review security scan findings in the context of how WordPress actually works at that scale, rather than reacting to every flag as an emergency or dismissing findings without review. What matters is a system where someone is actually looking, on a schedule, and knows the difference between noise and a real gap.
Password policy and two-factor authentication still matter. They just solve for how someone gets in, not what happens after. Least privilege solves for that second question, and most WordPress security conversations spend almost no time on it, which is backward, because it's the question that decides how bad your worst day actually gets.
If you're not sure how many Administrator accounts are currently active on your site, or why, that's usually the first place to look.
