XML-RPC is a WordPress feature that can be useful for remote publishing and integrations, but it is also a common target for password-guessing attacks.
If you want to reduce risk without disrupting your site, it helps to understand how to block XML RPC brute force attacks with the right mix of server rules, WordPress controls, and monitoring.
What XML-RPC is and why attackers target it
XML-RPC is a protocol that allows external applications to communicate with WordPress through xmlrpc.php.
It can support mobile apps, desktop editors, Jetpack, and some third-party publishing tools.
Attackers like XML-RPC because it can be abused for repeated login attempts.
Instead of hitting the normal login page one request at a time, they may use system.multicall to pack many login guesses into a single request.
That makes brute force attacks faster and easier to scale.
- High request volume: Attackers can test many username and password combinations quickly.
- Reduced visibility: Some brute force activity is less obvious than repeated login form submissions.
- Credential stuffing risk: Leaked passwords from other breaches are often reused against WordPress sites.
How XML-RPC brute force attacks work
A typical XML-RPC brute force attack sends requests to /xmlrpc.php and uses the system.multicall method or the wp.getUsersBlogs method to test credentials.
If the site accepts the request, the attacker gets useful feedback and keeps trying.
This is different from a normal failed login on /wp-login.php.
A single XML-RPC request can contain dozens or even hundreds of login attempts, which increases server load and can make rate limiting more important than simple password policy alone.
How to block XML RPC brute force attacks at the server level
The most effective protection starts at the web server or security layer.
Blocking or rate limiting requests before they reach WordPress reduces load and cuts off attack traffic early.
Disable XML-RPC entirely if you do not need it
If your site does not use Jetpack, remote publishing, the WordPress mobile app, or any other XML-RPC-dependent integration, disabling the endpoint is often the simplest option.
On Apache, this is commonly done through .htaccess rules; on Nginx, it is usually handled in the server configuration.
Disabling the endpoint prevents direct abuse, but it may break some tools that still rely on XML-RPC.
Check your publishing workflow before turning it off.
Use a web application firewall
A WAF such as Cloudflare, Sucuri, or a hosting provider’s firewall can block abusive requests to xmlrpc.php before they reach WordPress.
Many WAFs can also detect repeated login patterns, suspicious user agents, and known attack signatures.
- IP reputation filtering: Stops known malicious networks.
- Rate limiting: Caps requests from the same source in a short time.
- Request filtering: Blocks XML-RPC methods commonly used for abuse.
Rate limit requests to xmlrpc.php
If you cannot disable XML-RPC, rate limiting is a strong alternative.
Limiting requests per minute to /xmlrpc.php can dramatically reduce the speed of brute force attempts while still allowing legitimate traffic.
For example, a low threshold with burst protection can help stop automated attacks, especially if your site has little or no legitimate XML-RPC traffic.
Rate limiting is often more practical than a full block for sites that use Jetpack or mobile publishing.
How to block XML RPC brute force attacks in WordPress
Server-side controls are strongest, but WordPress-level hardening adds another layer of defense.
These measures reduce the chance that an attacker who reaches the site can succeed.
Limit login attempts
Although XML-RPC attacks may not hit the standard login form, many security plugins still help by restricting authentication abuse across the site.
Plugins such as Wordfence, iThemes Security, and Login LockDown can slow down repeated failures and flag suspicious behavior.
Look for settings that track usernames, IP addresses, and failed authentication attempts.
Logging matters because brute force attacks often happen in waves rather than as one isolated event.
Use two-factor authentication
Two-factor authentication adds an extra verification step beyond the password.
Even if an attacker guesses or steals a password, they still need the second factor to log in.
This is especially valuable for administrator, editor, and custom account roles with publishing access.
Protecting the highest-privilege accounts gives the best return on security effort.
Remove weak accounts and unused admin users
Attackers often target common usernames such as admin, editor, or the site owner’s public display name.
Use unique usernames that are not visible publicly, and delete unused accounts rather than leaving them dormant.
- Use strong, unique passwords for every account.
- Disable or remove old staff accounts.
- Review user roles regularly.
Should you disable system.multicall?
system.multicall is one of the most abused XML-RPC methods because it allows multiple method calls in a single request.
Blocking it can sharply reduce the effectiveness of brute force automation.
Some sites use system.multicall legitimately, so the decision depends on your workflow.
If you do not need it, blocking it at the WAF or server level is a smart defensive move.
If you do need XML-RPC, consider restricting only the abusive methods rather than the entire endpoint.
How to monitor and verify protection
After applying a control, verify that it works and that it does not interrupt normal site functions.
Check access logs, firewall events, and WordPress security plugin reports for denied requests to xmlrpc.php.
Useful signals include repeated POST requests to the endpoint, identical login attempts from rotating IPs, and spikes in response codes such as 401, 403, or 429.
Monitoring helps you distinguish blocked attacks from real usage.
Test legitimate features
If you use Jetpack, the WordPress mobile app, remote editors, or automated publishing tools, test them after making changes.
A security control that breaks publishing is not a good long-term solution.
Before and after each change, confirm that:
- Mobile publishing still works.
- Remote media uploads still sync correctly.
- Any connected services can authenticate.
Best-practice defense stack for WordPress sites
The strongest approach is layered defense.
No single control stops every attack, but combining several makes brute force attempts much less effective.
- Disable XML-RPC if you do not need it.
- Use a WAF to filter suspicious traffic.
- Rate limit requests to
xmlrpc.php. - Enable 2FA for all important accounts.
- Use unique usernames and strong passwords across the site.
- Monitor logs for spikes in request volume or denied access.
For many WordPress sites, the best answer to how to block XML RPC brute force attacks is not one single setting, but a combination of endpoint restriction, traffic filtering, and account protection.
That layered approach reduces risk while preserving the features your site actually needs.