The one-sentence version
Broken access control means a user can perform an action or see data that their actual permission level should never allow — not because they stole a password or forged anything, but because the code never actually checked whether they were allowed to do it in the first place.
A logged-in Subscriber — the lowest, most restricted WordPress role — triggers an action that's supposed to require Administrator. An anonymous, unauthenticated visitor hits an endpoint meant only for a logged-in staff account. In both cases, the system had every opportunity to say "you don't have permission for this" and simply never asked the question.
Why this is a different kind of bug than XSS, SQL injection, or CSRF
It helps to see how this differs from the other vulnerability types in this series. Cross-site scripting is about getting malicious script to run in someone else's browser. SQL injection is about getting untrusted input treated as a database command. CSRF is about forging a request using a victim's own authenticated session. All three involve tricking the system into doing something with attacker-supplied input or a forged action.
Broken access control needs none of that. The request can be completely genuine, sent directly and honestly by the attacker's own browser, using the attacker's own (possibly very low-privilege, or entirely absent) account. The bug isn't in how the request is crafted — it's in the fact that the endpoint receiving it never checked who was allowed to call it. It's a missing question, not a manipulated answer.
What this looks like in a real WordPress plugin
The pattern shows up constantly in plugin AJAX handlers and REST API endpoints. A developer builds a feature — say, an endpoint that creates a new site connection, imports data, or changes a setting — and wires up the logic correctly. But the function that actually executes the sensitive action never calls WordPress's own permission-checking functions, like current_user_can(), before running.
The result: the endpoint works exactly as intended for a legitimate admin, and also works exactly the same way for literally anyone who sends the same request — a Subscriber, a logged-out visitor, an automated script. Nothing about the request looks malformed or suspicious, because nothing about it is. It's a completely ordinary request to an endpoint that simply never asked "should this person be allowed to do this?"
Why OWASP ranks this as the single most serious web vulnerability category
This isn't a niche WordPress-specific concern. OWASP's Top 10 — the industry-standard reference for web application security risks — ranks A01: Broken Access Control as the #1 category, moved up from 5th place in the prior edition, with some form of broken access control detected in 94% of tested applications. It's rated highest not because any single instance is exotic, but because the category is both extremely common and, when it hits, the impact is close to maximal: it goes straight to unauthorized access or full account takeover, with none of the extra steps an attacker would otherwise need.
A real, verified example
In April 2025, security researchers disclosed CVE-2025-27007, a critical vulnerability in OttoKit (formerly SureTriggers), a workflow-automation plugin used on 100,000+ sites, affecting all versions up to and including 1.0.82, with a CVSS score of 9.8 (critical). It's classified as CWE-266, Incorrect Privilege Assignment — the formal name for exactly this bug class.
The plugin's create_wp_connection() function — used to authenticate a connection between OttoKit and the WordPress site — failed to properly verify the request when the plugin's own application-password/secret-key setup hadn't been completed yet. On any site where that initial setup step hadn't run, the function would accept a connection request from anyone, with no credential check at all, and that connection could then be used to create a brand-new WordPress account with the Administrator role. No password guessing, no forged session, no injected code — just a direct request to an endpoint that never verified who was making it. The issue was patched in version 1.0.83.
Why this is (almost always) a plugin problem
The same pattern holds as with the other vulnerability types in this series: WordPress core's own capability-checking system, built around functions like current_user_can(), is mature and consistently applied across core's own admin actions. Real-world broken access control disclosures in WordPress are overwhelmingly plugin and theme code — a new AJAX action, REST route, or admin-post handler that the developer added without wiring in the corresponding permission check. The more "powerful" a plugin feature is (creating users, changing site settings, connecting external integrations, importing data), the more damage a missing check on that specific endpoint can do.
What to actually do about it
- Keep every plugin and theme updated, promptly. Like the other vulnerability classes covered in this series, virtually every real broken-access-control disclosure — including the OttoKit case above — is a patched, known issue by the time it's public.
- Limit how many accounts hold elevated roles. Broken access control bugs matter most when they can reach an Administrator-level action; keeping the number of Administrator and Editor accounts to the minimum you actually need reduces what's exposed even before a specific bug is found.
- Be cautious with plugins that connect your site to external services or automation platforms — these often need to create accounts, connections, or elevated permissions programmatically, which is exactly the kind of endpoint where a missing permission check does the most damage, as the OttoKit case shows.
Get file, account, and login findings explained the moment they happen — not months later.
Install free →