How to Disable XML-RPC in WordPress to Stop Brute Force Attacks

If you check your WordPress access logs, you'll likely find hundreds — sometimes thousands — of requests hitting /xmlrpc.php every day. This is a brute force attack where hackers exploit the XML-RPC interface to test username and password combinations at scale, bypassing normal login rate limiting.

This guide explains what XML-RPC is, why it's dangerous, and exactly how to disable it.

What Is XML-RPC?

XML-RPC is a legacy protocol that allows external applications to interact with WordPress remotely via the xmlrpc.php file. It was originally created for the WordPress mobile app and services like Jetpack to post content and manage sites remotely.

Today, WordPress has a modern and more secure REST API that handles these tasks. For most sites, XML-RPC is unnecessary and represents an unneeded attack surface.

Why Is XML-RPC Dangerous?

There are three main attack vectors through XML-RPC:

• Multicall Brute Force — XML-RPC supports batching multiple calls in one request (system.multicall). Attackers can test thousands of password combinations in a single HTTP request, easily bypassing IP-based rate limiting.
• DDoS Amplification via Pingback — The pingback.ping method can be abused to make your server send requests to a third-party target, effectively turning your site into a DDoS participant and getting your IP blacklisted.
• Remote Content Injection — Once credentials are obtained, attackers can post malicious content or modify your site through XML-RPC without ever touching the admin login page.

Method 1 — Block via .htaccess (Recommended)

This method blocks requests to xmlrpc.php at the web server level, before PHP runs. It's the most efficient approach and uses zero WordPress resources.

Add the following to your .htaccess file (in the WordPress root, same directory as wp-config.php):

# Block xmlrpc.php completely
<Files xmlrpc.php>
  Order Deny,Allow
  Deny from all
</Files>

Alternatively:

<IfModule mod_rewrite.c>
  RewriteRule ^xmlrpc\.php$ - [F,L]
</IfModule>

After saving, test by visiting yoursite.com/xmlrpc.php — you should see 403 Forbidden.

Method 2 — Use a Plugin (Easiest for Beginners)

If you prefer not to edit .htaccess directly, use one of these plugins:

• Disable XML-RPC — A lightweight single-purpose plugin. Free, no configuration needed.
• Wordfence Security — Full security suite with XML-RPC blocking in settings.
• All-in-One Security (AIOS) — Has a "Complete Block XML-RPC" option under WordPress Tweaks.

Method 3 — Selective Disable via functions.php

Use this if you need XML-RPC for some services (like Jetpack) but want to block the most dangerous methods:

// Disable XML-RPC entirely (breaks Jetpack)
add_filter('xmlrpc_enabled', '__return_false');

// Or: just block pingback to prevent DDoS amplification
add_filter('xmlrpc_methods', function($methods) {
    unset($methods['pingback.ping']);
    unset($methods['pingback.extensions.getPingbacks']);
    return $methods;
});

Add this to your Child Theme's functions.php or use the Code Snippets plugin to avoid touching theme files directly.

How to Verify the Block Is Working

1. Open your browser and navigate to https://yoursite.com/xmlrpc.php
2. If you see 403 Forbidden or 404 Not Found — success, it's blocked.
3. If you see "XML-RPC server accepts POST requests only" — it's still active. Review the steps above.

Additional WordPress Security Measures

Disabling XML-RPC is one of many hardening steps you should take. Other important measures include:

• Rename or restrict access to the /wp-admin login page
• Enable Two-Factor Authentication (2FA) for all admin accounts
• Limit login attempts with a plugin like Login LockDown
• Keep WordPress core, themes, and plugins updated at all times
• Install a security plugin like Wordfence or Sucuri

Blocking xmlrpc.php Attackers Automatically with Fail2ban

Even after blocking xmlrpc.php via .htaccess, bots will keep sending requests and generating noise in your logs. Fail2ban reads your access logs in real time and automatically bans offending IP addresses, eliminating the wasted bandwidth.

Install Fail2ban on Ubuntu

sudo apt install fail2ban -y
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

Create a Custom Filter for xmlrpc.php

Create the file /etc/fail2ban/filter.d/wordpress-xmlrpc.conf:

[Definition]
failregex = ^<HOST> .* "POST /xmlrpc.php.*" (200|403|404|500) .*$
ignoreregex =

Set Up the Jail

Add the following to /etc/fail2ban/jail.local:

[wordpress-xmlrpc]
enabled  = true
port     = http,https
filter   = wordpress-xmlrpc
logpath  = /var/log/apache2/access.log
maxretry = 5
findtime = 60
bantime  = 3600

This bans any IP that hits xmlrpc.php more than 5 times in 60 seconds, for 1 hour. Set bantime = -1 for a permanent ban of repeat offenders. Apply the changes:

sudo fail2ban-client reload
sudo fail2ban-client status wordpress-xmlrpc

XML-RPC vs WordPress REST API: Key Differences

A common concern when disabling XML-RPC is losing remote API access. The good news: WordPress's modern REST API handles all the same use cases — more securely.

The REST API is accessible at /wp-json/wp/v2/ and supports granular access to posts, pages, users, taxonomies, and more through standard HTTP methods. If a third-party service still requires XML-RPC in 2026, it's worth checking whether a REST API alternative exists — most modern WordPress tools have already migrated.

Checking Your Access Logs for xmlrpc.php Attacks

Before or after applying a block, it's useful to see how heavily your site is being targeted. On servers with Apache, run these commands via SSH to analyze your access log:

# Count total xmlrpc.php requests in the current log
grep "xmlrpc.php" /var/log/apache2/access.log | wc -l

# List the top attacking IP addresses
grep "xmlrpc.php" /var/log/apache2/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

# Watch for new requests in real time
tail -f /var/log/apache2/access.log | grep xmlrpc

If you see more than 100 requests per day to xmlrpc.php — or the same IP appearing hundreds of times — your site is actively being targeted. Apply the .htaccess block immediately, then consider adding those IPs to a blocklist using Fail2ban or a WAF rule to stop them before they reach your server at all.