WordPress user roles control who can do what on your site. A misconfigured role, or worse, an unnecessary admin account, is one of the fastest ways to get hacked. This guide covers every default role, the security risks each one carries, and how to lock them down properly. We will cover custom role creation, user enumeration protection, monitoring, and best practices for least privilege access.
WordPress user roles permissions security guide: The Five Default WordPress Roles
WordPress ships with six default roles: Super Admin (multisite only), Administrator, Editor, Author, Contributor, and Subscriber. Each has a specific capability set that determines what a user can see, create, edit, publish, and delete. Most site owners set up user accounts during initial configuration and never review them again. This is a security risk that grows over time as employees leave, roles change, and unused accounts accumulate.
Understanding what each role can actually do is the first step toward proper access control. Let us examine each role in detail, including the specific capabilities, the security risks, and realistic attack scenarios.
WordPress user roles permissions security guide: Administrator: The Most Dangerous Role
Administrators can do absolutely everything on a WordPress site: install and delete plugins, edit themes, create and delete users, modify files, change site settings, and manage the entire content library. If an attacker compromises an admin account, the site is theirs. They can install backdoor plugins, delete your content, steal your database, or redirect your traffic to malicious sites.
Best practice: only give Administrator to people who absolutely need it. For everyone else, create an Editor account instead. Limit admin accounts to 2-3 people maximum. Each additional admin account expands your attack surface and makes it harder to track who changed what.
Also check for stale admin accounts. Old employee accounts, test accounts created during development, and default “admin” accounts are common attack vectors. If you find accounts you don’t recognize, investigate immediately. They could be a sign of a breach. See our guide on mysterious admin accounts for what to do next.
Attack scenario: An attacker obtains admin credentials through a phishing email. Within 60 seconds of logging in, they install a plugin that creates a hidden admin account, exfiltrates the user database, and injects malicious JavaScript into the site footer. You may not notice for days or weeks. By then, every visitor to your site has been exposed to malware.
Editor: Full Content Control Without System Access
Editors can publish, edit, and delete any post or page on the site, including those written by other users. They can manage categories, tags, and comments. However, they cannot install plugins, change themes, modify files, or manage users.
Security risk: Editors are a prime target for privilege escalation (The Admin Account Nobody Created) attacks. If an attacker compromises an Editor account, they can publish malicious content, inject harmful shortcodes, or modify existing posts to include malware. They can also delete critical pages, causing SEO damage and disruption.
Attack scenario: An attacker gains access to an Editor account via a reused password from a data breach. They edit an existing blog post that ranks well on Google, adding hidden spam links or iframes. The compromised post continues to rank, distributing malware to your visitors for weeks before anyone notices the subtle content change.
Author: Publishing Power with File Upload Risks
Authors can publish and edit their own posts. They can also upload files (images, documents, and media) to the WordPress media library. This file upload capability is one of the most exploited features in WordPress security incidents.
Security risk: Authors can upload files to the wp-content/uploads directory. If the upload handler has a vulnerability, or if PHP execution is not blocked in the uploads directory, an attacker with an Author account can upload a PHP shell and execute arbitrary code on your server. This is why blocking PHP execution in wp-content/uploads is critical (covered in our .htaccess security guide).
Attack scenario: An attacker signs up for an Author account (if registration is enabled) and uploads a PHP file disguised as a JPEG. The server does not block PHP execution in uploads. The attacker accesses the uploaded file directly and gains remote code execution on your server. They then use that access to install a cryptominer or exfiltrate your database.
Contributor: Write Access Without Publishing
Contributors can write and edit their own posts but cannot publish them. They cannot upload files. An Editor or Administrator must review and publish Contributor submissions.
Security risk: Contributors are relatively low risk for direct damage, but they can still submit posts containing malicious shortcodes, harmful HTML, or content that exploits other vulnerabilities. An attacker with a Contributor account can probe your site for vulnerabilities, use the REST API for user enumeration, and gather intelligence before attempting privilege escalation.
Attack scenario: An attacker registers as a Contributor and uses the WordPress REST API to enumerate all users on the site, building a list of usernames for a brute force attack against admin accounts. They also probe for outdated plugins by examining the source code of admin-side features they can access through the block editor.
Subscriber: The Most Limited Role
Subscribers can only manage their own profile: change their password, update their email, and view their comments. They cannot write posts, upload files, or access any admin features beyond their profile page.
Security risk: While Subscribers have very limited capabilities, they still represent an attack surface. A compromised Subscriber account can be used for user enumeration via the REST API, brute force probing, and social engineering. If your site allows registration, an attacker can create Subscriber accounts at scale to probe for vulnerabilities without detection.
Attack scenario: An automated script registers hundreds of Subscriber accounts on your site. These accounts probe the REST API for user data, test common vulnerability patterns in your plugins, and report back to a command server. Because Subscriber accounts look like legitimate users, they may not trigger your security alerts.
Super Admin: Multisite Network Control
Super Admin is available only on WordPress Multisite networks. A Super Admin can manage every site in the network, install and activate plugins network-wide, manage themes, and create or delete subsites. Compromising a Super Admin account means complete control over every site in the network.
Security risk: Multisite environments compound the damage potential. A compromised Super Admin account on a network with 100 client sites means 100 sites are compromised at once. Super Admin accounts should be limited to absolute minimum, require strong 2FA, and be monitored continuously.
How Attackers Exploit Weak Role Management
Attackers have several techniques for exploiting weak role management in WordPress. Understanding these methods helps you defend against them.
- User enumeration via REST API: Even with a Subscriber account, attackers can enumerate all users on your site through the /wp/v2/users endpoint. Trusti Security can disable REST API user enumeration with one toggle.
- Author archive scanning: Attackers scan /author/1, /author/2, and so on to build a username list for brute force attacks. This works even with closed registration if you have any public authors.
- File upload in Author/Contributor roles: Authors can upload images. If the upload handler has a vulnerability, that can mean arbitrary file upload and remote code execution.
- Privilege escalation via plugin vulnerabilities: Role management plugins or membership plugins with bugs can allow users to escalate their privileges to Administrator level.
- Session hijacking of idle accounts: Old accounts with weak passwords that no one monitors are prime targets. Attackers compromise these and use them as footholds for lateral movement.
How to Check Current Users
Regular user auditing is essential. Here is how to check your users both through the admin interface and programmatically:
Via WordPress Admin
Go to Users > All Users in your WordPress dashboard. Review every account. Look for:
- Usernames you do not recognize
- Users with Administrator role who should not have it
- Users who have not logged in for more than 90 days
- Suspicious email addresses (especially free email domains for business sites)
- Multiple accounts with similar usernames
Via WP-CLI
WP-CLI gives you a clean way to list and inspect users from the command line:
# List all users with their roles
wp user list --fields=ID,user_login,display_name,roles,user_email
# List only administrators
wp user list --role=administrator --fields=ID,user_login,user_email
# Count users by role
wp user list --field=roles | sort | uniq -c | sort -rn
# Show user details including last login
wp user get <user_id> --fields=user_login,user_email,roles,registeredVia Direct Database Query
For advanced auditing, you can query the database directly. Run this SQL command in phpMyAdmin or via WP-CLI:
SELECT user_login, user_email, display_name
FROM wp_users
WHERE ID IN (
SELECT user_id FROM wp_usermeta
WHERE meta_key = 'wp_capabilities'
AND meta_value LIKE '%administrator%'
);Creating Custom Roles with Code
Sometimes the default roles do not fit your needs. You can create custom roles by adding code to your theme’s functions.php file or a custom plugin. Here is how to create a custom role with specific capabilities:
// Add this to your theme's functions.php or a custom plugin
function trustiwp_add_custom_roles() {
// Create a "Content Manager" role
add_role(
'content_manager',
'Content Manager',
array(
'read' => true,
'edit_posts' => true,
'edit_others_posts' => true,
'publish_posts' => true,
'edit_published_posts' => true,
'delete_posts' => true,
'delete_others_posts' => false,
'upload_files' => true,
'moderate_comments' => true,
'manage_categories' => true,
'edit_theme_options' => false,
'install_plugins' => false,
'edit_users' => false,
)
);
}
add_action('init', 'trustiwp_add_custom_roles');To remove a custom role:
remove_role('content_manager');Adding Custom Capabilities
You can also add custom capabilities to existing roles. This is useful when you have a plugin that registers custom post types or features:
// Add custom capability to Editors
function trustiwp_add_custom_cap() {
$role = get_role('editor');
$role->add_cap('manage_project_settings', true);
}
add_action('admin_init', 'trustiwp_add_custom_cap');User Enumeration Protection
User enumeration is one of the most common pre-attack reconnaissance techniques. Attackers discover valid usernames, then use them for brute force password guessing. Here is how to block it.
Block Author Enumeration via .htaccess
Add this rule to your root .htaccess file to block author archive scanning:
# Block author enumeration
RewriteEngine On
RewriteBase /
RewriteCond %{QUERY_STRING} ^author=([0-9]*)
RewriteRule .* - [F,L]Block REST API User Endpoint
Add this to functions.php to restrict the REST API users endpoint:
// Restrict REST API user endpoint
function trustiwp_restrict_user_rest_api($response, $handler) {
if (!current_user_can('edit_users')) {
return new WP_Error(
'rest_user_cannot_view',
'You are not authorized to view users.',
array('status' => 401)
);
}
return $response;
}
add_filter('rest_pre_dispatch', 'trustiwp_restrict_user_rest_api', 10, 2);Monitoring User Changes
Attackers who gain admin access often create hidden admin accounts so they can return later. Monitoring for new user creation and role changes is critical. Trusti Security's Admin Activity Log (Admin Activity Logging guide) tracks every user-related change in real time: new user registrations, role changes, password resets, and profile updates. You receive alerts when a new Administrator account is created.
You can also set up manual monitoring using WP-CLI cron jobs. This script checks for new admin users and emails you if any are found:
#!/bin/bash
# Add to crontab to run daily
WP_PATH="/path/to/wordpress"
ADMIN_LIST=$(wp user list --role=administrator --field=user_login --path="$WP_PATH" 2>/dev/null)
echo "Admin users: $ADMIN_LIST"Removing Unused Users
Users who no longer need access should be removed or demoted immediately. Here is how to handle user cleanup:
Via WP-CLI
# Delete a user and reassign their posts to another user
wp user delete <user_id> --reassign=<new_owner_id>
# Remove a specific role from a user (demote)
wp user remove-role <user_id> administrator
wp user add-role <user_id> editorBulk User Cleanup
For bulk cleanup of users who have not logged in for a specific period:
# Find users who registered more than 6 months ago and never logged in
wp user list --field=ID | while read uid; do
LAST_LOGIN=$(wp user meta get $uid last_login 2>/dev/null)
if [ -z "$LAST_LOGIN" ]; then
echo "User $uid has never logged in"
fi
doneWP-CLI Commands for User Management
WP-CLI is the most efficient way to manage users at scale. Here are essential commands:
# Create a new user with specific role
wp user create johndoe john@example.com --role=editor --user_pass=secure_password
# List users with specific capabilities
wp user list --cap=manage_options
# Update user role
wp user set-role 123 editor
# Add capability to role
wp cap add 'editor' 'manage_project_settings'
# List all capabilities of a role
wp cap list 'administrator'
# Show user activity (if plugin supports it)
wp user session list 123The Principle of Least Privilege
Every user should have the minimum permissions needed to do their job. A content writer does not need plugin installation access. A developer who left the company six months ago should not still have an active admin account. Review your user list quarterly and clean up old accounts.
Create a user role matrix for your organization. Document who has what role and why. When someone changes roles internally, update their WordPress access accordingly. When someone leaves, remove their access the same day.
For agencies managing multiple client sites, implement a standardized role policy across all sites. Editors manage content. Administrators manage technical configuration. No client site should have more than two Administrator accounts.
Trusti Security for Role-Based Protection
Trusti Security gives you several tools for user role management: role-based 2FA enforcement (force certain roles to use 2FA), Pwned Passwords checking at login (Premium), Admin Activity Log tracking of user changes, and user enumeration blocking. No extra plugins needed.
User roles are not a set-and-forget setting. Review them regularly, enforce 2FA on privileged accounts, and monitor for unexpected changes. That alone closes one of the most common attack paths in WordPress.