XML-RPC & User Enumeration
Check if xmlrpc.php is open and whether your usernames leak.
Demo tool - results are sample data, not a live lookup.
About the XML-RPC & User Enumeration
Two classic WordPress attack surfaces are xmlrpc.php and user enumeration. xmlrpc.php can be abused for brute-force amplification and pingback attacks, while the REST API endpoint /wp-json/wp/v2/users and the ?author=1 query can hand attackers a list of valid usernames to target.
This tool checks whether those endpoints are exposed, so you can decide whether to disable XML-RPC and block user enumeration before a bot finds them for you.
How to use it
- 1Enter your WordPress site's address.
- 2Run the check to see whether xmlrpc.php responds and whether usernames are exposed.
- 3If they're open, disable XML-RPC (if unused) and block author/REST user enumeration via a plugin or firewall rule.
What it checks
- xmlrpc.php
- Legacy remote API. Often unused today and a common brute-force / pingback target.
- REST /users endpoint
- /wp-json/wp/v2/users can list account usernames if left public.
- ?author=1 redirect
- Requesting an author archive by ID can reveal the account's login slug.
- Recommendation
- Disable XML-RPC when unused and restrict user endpoints to authenticated requests.
Frequently asked questions
Should I just disable XML-RPC?
If nothing you use depends on it (some older apps and Jetpack features do), disabling it removes a whole class of attacks. Otherwise, rate-limit and challenge it instead.
Why does username enumeration matter?
Knowing a valid username is half of a brute-force attempt. Hiding usernames forces attackers to guess both fields.
How do I block this on WordPress?
A security plugin or firewall (or CDN rules) can disable xmlrpc.php, block ?author= scans, and require authentication for the REST users endpoint.
Run WordPress on infrastructure built for it.
Performance, security, and the WordPress tooling you need - fully managed, so these checks stay green.