Every WordPress site stores a "silent" file in the root that most owners only discover after an attack. Its name is xmlrpc.php. The file itself isn't malicious: WordPress honestly warns that it's an interface for remote interaction. But it's through this file that bots have been brute-forcing passwords, sending spam pingbacks, and driving DDoS traffic for years.

According to Wordfence data for 2024, attacks via XML-RPC are among the top five attack vectors against WordPress sites. A single system.multicall request allows an attacker to test hundreds of passwords at once, instead of one like through the login form. Hosting providers register millions of such attempts monthly on an average site.

Let's understand why this file is needed at all, who should keep it, and most importantly, show five ways to disable or securely block xmlrpc.php, from a one-click plugin to targeted .htaccess edits.

💡 Quick overview:

• Learn what xmlrpc.php is and which WordPress functions depend on it (pingback, mobile app, Jetpack)
• Assess real risks: brute-force amplification, pingback DDoS, and directory scanning by bots
• Choose the right protection method: disabling via plugin, blocking through .htaccess, closing access at the web server level, or removing the file
• Set up monitoring: how to make sure xmlrpc.php no longer responds to requests

What xmlrpc.php is and which WordPress functions depend on it

XML-RPC is a remote procedure call protocol that works over HTTP and transmits data in XML format. The technology appeared in the late 1990s, long before REST API, and WordPress inherited it in its early days. The xmlrpc.php file in the site root accepts XML requests, processes them, and returns a response, for example, publishes a post, uploads a media file, or checks user permissions.

In practice, several scenarios work through xmlrpc.php:

• Pingbacks and trackbacks. When someone links to your post, their site sends an XML-RPC request with a notification. Your WordPress checks the link and, if it's real, adds the pingback to comments.

• Remote publishing. Applications like the old Windows Live Writer or desktop clients (TextMate, MarsEdit) used XML-RPC to write and send posts without entering the admin panel.

• WordPress mobile app. The official iOS and Android app relied on XML-RPC for a long time, although it's increasingly moving to REST API now.

• Integrations. Services like Jetpack (part of its functionality), IFTTT, and some SEO tools still use XML-RPC to connect to the site.

With the release of WordPress REST API in version 4.7 (December 2016), most modern integrations moved to the new protocol. REST API is faster, works with JSON instead of XML, and is better documented. Nevertheless, WordPress still includes xmlrpc.php in every installation for backward compatibility.

Important nuance: starting with WordPress 2.6 (back in 2008), remote publishing functionality via XML-RPC is disabled by default. To enable it, you need to explicitly check the box in "Settings → Writing". Pingbacks and trackbacks continue to work at the same time.

How xmlrpc.php is dangerous: three main attack vectors

WordPress developers have patched xmlrpc.php more than once. In version 2.1.2, an authenticated user with "contributor" rights could publish a post bypassing restrictions. In 2.3.1, they discovered an information leak through XML-RPC. Both holes were quickly closed, but the protocol itself remained architecturally vulnerable to three classes of attacks that are still relevant in 2026.

Brute-force amplification via system.multicall

The main problem is the system.multicall method. It allows packing multiple wp.getUsersBlogs calls into one HTTP request. Each call checks a "login + password" pair. So, instead of one guess per request, the attacker makes hundreds. Cloudflare has recorded peaks of tens of thousands of such requests per hour on a single site.

The regular login form wp-login.php is limited to one login per attempt and is easily protected by a plugin like Wordfence or Limit Login Attempts. xmlrpc.php bypasses all these limiters because it works through a different endpoint.

Pingback DDoS

The pingback feature is designed as a harmless notification. But an attacker can send fake pingback requests on behalf of hundreds of sites, and your server will go check each "link", loading the CPU, network, and database. With sufficient scale, the site goes down. Sucuri in its 2023 report calls pingback attacks one of the most common DDoS vectors against WordPress.

Directory scanning by bots

Bots look for xmlrpc.php not only in the root but also in made-up subdirectories like /2026/01/xmlrpc.php and /blog/xmlrpc.php. Each such request returns a 404 and wastes server resources. Even if the attack failed, tens of thousands of junk requests slow down the site and clog the logs. In practice, owners see graphing in cPanel go into the red zone, and the reason is precisely bots scanning xmlrpc.php.

5 ways to disable or secure xmlrpc.php

Below are five methods, from the simplest to the most radical. Choose based on your situation: whether you use the mobile app, whether you need pingbacks, what hosting you have.

1. Disable via plugin

The safest path for those who don't want to touch the code. Install a plugin, and it will block access to xmlrpc.php at the WordPress level, before request processing begins.

Pros: no need to edit .htaccess or functions.php, easy to turn back on. Cons: adds another plugin to the admin panel, protection is removed on deactivation.

A couple of proven options:

• Disable XML-RPC, minimalist, one action: activated, and access is closed. No settings.
• Wordfence Security, comprehensive firewall in which disabling XML-RPC is just one of the functions. Suitable if you already use Wordfence or plan to install it.

2. Block via.htaccess

If you're working on an Apache server, the .htaccess file in the site root allows you to block access before the request reaches WordPress. This reduces load: Apache returns 403 Forbidden immediately, without running PHP.

Add the following block to .htaccess at the beginning of the file, before # BEGIN WordPress:

1
<IfModule mod_alias.c>
2
    RedirectMatch 403 /(.*)/xmlrpc.php$
3
</IfModule>

The RedirectMatch 403 directive catches any URL ending in /xmlrpc.php, including subdirectories like /2025/06/xmlrpc.php, and instantly returns 403.

Pros: doesn't touch WordPress code, works before PHP loads, saves resources. Cons: need to edit .htaccess manually, when changing hosting or theme the file may be overwritten.

Important: before editing .htaccess, make a backup. An error in .htaccess syntax can bring down the site (500 Internal Server Error).

3. Remove links via functions.php

This method doesn't block the file itself but removes HTML links to xmlrpc.php and wlwmanifest.xml from the <head> section of the site. The benefit is reduced visibility: bots parsing HTML don't see a direct pointer to the XML-RPC endpoint.

Add to the active theme's functions.php (or via the Code Snippets plugin):

1
remove_action('wp_head', 'rsd_link');
2
remove_action('wp_head', 'wlwmanifest_link');

The rsd_link hook outputs <link rel="EditURI">, a link to xmlrpc.php for Really Simple Discovery clients. The wlwmanifest_link hook is for Windows Live Writer (long unsupported, but WordPress still outputs it).

Pros: clean <head> without junk links. Cons: xmlrpc.php physically remains accessible via direct URL, this is not blocking but masking.

4. Close access via WAF or Cloudflare

Web Application Firewall blocks requests to xmlrpc.php before they reach your server. This is the most effective approach for sites on any hosting.

Configuration options:

• Cloudflare (free tier): WAF Rule → Block → URI Path field contains /xmlrpc.php. The request is rejected at the Cloudflare network level, your server doesn't even see it.
• Wordfence WAF: Built-in "Disable XML-RPC" function in the firewall section.
• Hosting WAF: Kinsta, WP Engine, and other managed hosters let you disable XML-RPC in a couple of clicks through the control panel.

Pros: zero server load, can be finely tuned (for example, allow Jetpack while blocking everything else). Cons: requires WAF-side configuration, not all hosting providers provide this capability.

5. Remove or rename the file itself

The most radical method. You delete (or rename) the xmlrpc.php file from the server. If the file physically doesn't exist, there's nothing to process requests, the server returns 404.

Important nuance: on the next WordPress update, the file will be restored. Automatic core updates overwrite all WordPress files, including xmlrpc.php. So deletion is a temporary measure unless you set up regular cleanup.

If you go this route, supplement the deletion with the .htaccess rule from method 2. Without it, bots will continue knocking on the xmlrpc.php URL, and the server will honestly return 404 on every request, thousands of errors in the logs.

Is it even worth disabling xmlrpc.php?

The answer depends on what you use. Go through the checklist:

If you don't use an old version of the mobile app, haven't enabled Jetpack management with WordPress.com, and pingbacks aren't critical for you, disable it without hesitation. In 2026, REST API covers almost all real scenarios.

Video: how to disable XML-RPC in WordPress in 5 minutes

Watch a visual guide to disabling xmlrpc.php, with screen demonstration and explanation of each method:

⁉️🤔 Frequently asked questions

Is it safe to just ignore xmlrpc.php?

In most cases, no. Even if you don't use XML-RPC, bots scan this endpoint constantly. Each such request loads the server. Better to explicitly close access via .htaccess or plugin, this removes both the brute-force risk and junk requests in the logs.

Will the site break if xmlrpc.php is disabled?

WordPress itself will continue to work without changes. Just check whether you're using Jetpack management with WordPress.com or an old version of the mobile app. If not, disable without worry. Pingbacks will stop coming, but most sites don't use them for real communication anyway.

How to check that xmlrpc.php is actually blocked?

Open in your browser https://your-site.com/xmlrpc.php. If you see a white screen with the message "XML-RPC server accepts POST requests only", the file is alive and responding. If you get 403 Forbidden or 404 Not Found, the block is working. For automatic monitoring, you can use online checkers like xmlrpc.eror.xyz or a curl request from the console.

What's better: plugin or.htaccess?

.htaccess blocks the request before WordPress launches, this saves server resources. A plugin is easier to install and doesn't require editing files. For non-critical sites there's almost no difference. For high-load projects, .htaccess or a WAF rule is preferable.

Do I need to update WordPress after disabling xmlrpc.php?

No. Disabling xmlrpc.php doesn't depend on WordPress version and doesn't affect core updates. The only nuance: if you deleted the file physically, the update will restore it, requiring deletion again.

So what should you do with xmlrpc.php on your site?

There's no universal answer, context decides everything. But the practice of thousands of WordPress sites gives a clear picture: if you don't know whether you need XML-RPC, you don't need it.

Want reliability without diving into code, install Disable XML-RPC. Ready to spend five minutes on .htaccess, get server-level protection without extra plugins. Using Cloudflare, set up a WAF rule and forget about the problem.

The main thing is don't leave xmlrpc.php open "by default". In 2026, every unclosed WordPress endpoint is a target for automated bots that don't care whether you have a blog or an online store. Close access using one of the methods above, check the result with a curl request, and sleep peacefully.