Why and How to Disable XML-RPC in WordPress (2025)

There’s a file on your WordPress site called xmlrpc.php. It sits quietly in your root directory, and you’ve probably never thought about it. But hackers think about it constantly.

XML-RPC is a legacy feature that most modern WordPress sites don’t need. Yet it remains enabled by default, providing attackers with a convenient entry point for brute force attacks, DDoS amplification, and other exploits.

In this guide, you’ll learn exactly what XML-RPC is, why it’s a security risk, how to check if you actually need it, and how to disable XML-RPC in WordPress safely.

What Is XML-RPC?

XML-RPC (Extensible Markup Language Remote Procedure Call) is a protocol that allows external applications to communicate with your WordPress site. It was created in the early days of WordPress when there was no REST API, providing a way for remote systems to interact with your site.

What XML-RPC Was Designed For

• Remote publishing: Write and publish posts from desktop applications like Windows Live Writer
• Mobile apps: The old WordPress mobile app used XML-RPC to communicate with sites
• Pingbacks and trackbacks: Notify other blogs when you link to them
• Third-party integrations: Services like IFTTT and some automation tools

The Problem: It’s Obsolete

WordPress introduced the REST API in 2016 (WordPress 4.7). This modern API does everything XML-RPC does, but better and more securely. The WordPress mobile app, Jetpack, and most modern integrations now use the REST API instead.

XML-RPC remains in WordPress for backward compatibility, but for most sites, it’s a security liability that serves no purpose.

Why XML-RPC Is a Security Risk

XML-RPC has several characteristics that make it attractive to attackers:

Amplified Brute Force Attacks

The standard WordPress login page allows one password attempt per request. XML-RPC’s system.multicall method allows attackers to try hundreds of username/password combinations in a single request.

This means:

• Login attempt rate limiting doesn’t work as well
• Attackers can test thousands of passwords quickly
• Failed login logging may not capture all attempts
• IP blocking triggers more slowly

An attacker can potentially test 500+ passwords in a single HTTP request, bypassing many security measures designed for the normal login page.

DDoS Amplification

XML-RPC’s pingback feature can be exploited for distributed denial of service (DDoS) attacks. Attackers can send pingback requests to thousands of WordPress sites, all pointing to a single target. Each WordPress site then sends traffic to the victim, amplifying the attack.

Your site becomes an unwitting participant in attacking others.

Information Disclosure

XML-RPC can reveal information about your WordPress installation:

• Confirmation that WordPress is installed
• Valid username enumeration
• Some plugin and configuration details

This reconnaissance helps attackers plan more targeted attacks.

No Modern Security Features

XML-RPC was designed before modern security practices became standard:

• No built-in rate limiting
• No two-factor authentication support
• No CAPTCHA integration
• Basic authentication only

XML-RPC is one of the most common attack vectors against WordPress sites. It’s targeted in over 90% of brute force attacks we observe. – Sucuri Security Report

Do You Actually Need XML-RPC?

Before disabling XML-RPC, determine if anything on your site relies on it:

You Probably DON’T Need It If:

• You write posts directly in the WordPress dashboard
• You use the current WordPress mobile app (it uses REST API now)
• You use Jetpack (it switched to REST API years ago)
• You don’t use pingbacks or trackbacks
• You’re not running any legacy integrations from before 2016

You MIGHT Need It If:

• You use very old desktop publishing applications
• You have legacy automation tools that haven’t been updated
• You use specific plugins that explicitly require XML-RPC (rare)
• You have a multi-site setup with older cross-posting features

How to Test

The safest approach:

1. Disable XML-RPC using one of the methods below
2. Test all your normal workflows for a week
3. If something breaks, identify what specifically needs XML-RPC
4. Either re-enable it or find a modern alternative

Most site owners disable XML-RPC and notice no difference whatsoever, because nothing was using it.

Test Before Committing

If you’re unsure whether anything uses XML-RPC, disable it temporarily and monitor for issues. The methods below are all reversible if you discover something breaks.

How to Disable XML-RPC in WordPress

There are several ways to disable XML-RPC, from simple plugin solutions to server-level blocking.

Method 1: Use a Security Plugin (Recommended)

The easiest and most reliable method is using a security plugin that handles XML-RPC blocking along with other protections.

Disable XML-RPC With One Click

Stack Guard disables XML-RPC by default, along with removing the X-Pingback header. Combined with brute force protection and login security, you’re protected from multiple attack vectors with a single plugin.

Download Stack Guard Free

With Stack Guard or similar security plugins:

1. Install and activate the plugin
2. Navigate to the security settings
3. Enable “Disable XML-RPC” (often enabled by default)
4. Save settings

The plugin blocks XML-RPC requests at the WordPress level and removes the X-Pingback header from your site’s responses.

Method 2: Add a Filter in functions.php

Add this code to your theme’s functions.php file or a custom plugin:

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

// Remove X-Pingback header
add_filter('wp_headers', function($headers) {
    unset($headers['X-Pingback']);
    return $headers;
});

This disables XML-RPC functionality and removes the header that advertises its presence.

Limitation: This blocks XML-RPC at the WordPress level, but the xmlrpc.php file still receives and processes the initial request before WordPress blocks it. For complete blocking, use server-level methods.

Method 3: Block via .htaccess (Apache)

For Apache servers, add this to your .htaccess file:

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

This blocks access at the server level, before WordPress even loads. It’s more efficient and more secure than PHP-level blocking.

Method 4: Block via nginx Configuration

For nginx servers, add this to your server block:

# Block WordPress xmlrpc.php
location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
}

Like the .htaccess method, this blocks requests at the server level.

Method 5: Block via Cloudflare

If you use Cloudflare, you can block XML-RPC at the edge before requests even reach your server:

1. Log into Cloudflare
2. Go to Security → WAF
3. Create a custom rule
4. Set the rule to block requests where URI Path contains “xmlrpc.php”
5. Deploy the rule

This is the most efficient method as it stops attacks before they consume any of your server resources.

Choosing the Right Method

Method	Best For	Efficiency
Security Plugin	Most users, simplest solution	Good
functions.php	Developers who want code control	Good
.htaccess / nginx	Performance-conscious users	Better
Cloudflare	High-traffic or frequently attacked sites	Best

You can combine methods for defense in depth. Using both a security plugin and Cloudflare rules, for example, provides multiple layers of protection.

Verifying XML-RPC Is Disabled

After disabling XML-RPC, verify it’s actually blocked:

Method 1: Direct Browser Test

1. Visit yoursite.com/xmlrpc.php in your browser
2. You should see a 403 Forbidden error, 404 Not Found, or a blank page
3. You should NOT see “XML-RPC server accepts POST requests only”

Method 2: Online Validator

Use an XML-RPC validator tool:

1. Search for “XML-RPC validator” online
2. Enter your site URL
3. A properly disabled site will fail to connect

Method 3: Check Response Headers

1. Open browser developer tools (F12)
2. Go to the Network tab
3. Visit any page on your site
4. Look at the response headers
5. The X-Pingback header should be absent

What If Something Breaks?

If you disable XML-RPC and something stops working, here’s how to troubleshoot:

Identify What Broke

• What specific feature or plugin stopped working?
• When did it last work?
• Does the plugin documentation mention XML-RPC?

Find an Alternative

Most XML-RPC-dependent features have modern alternatives:

• Mobile publishing: Use the WordPress app (REST API) or web interface
• Desktop publishing: Use the web interface or find an updated app
• Automation: Update to tools that use REST API (Zapier, Make, etc.)
• Pingbacks: Consider disabling anyway (mostly spam these days)

Selective Enabling (Last Resort)

If you absolutely must use XML-RPC for a specific purpose:

1. Re-enable XML-RPC
2. Use IP allowlisting to restrict access to known, trusted IPs only
3. Monitor access logs for suspicious activity
4. Implement additional brute force protection

This is not recommended for most sites, but it’s better than leaving XML-RPC completely open.

Don’t Leave XML-RPC Open

If you must use XML-RPC, combine it with strong brute force protection and monitor it closely. An open XML-RPC endpoint without protection is actively being scanned and attacked right now.

Frequently Asked Questions

Will disabling XML-RPC break Jetpack?

No. Jetpack switched from XML-RPC to the WordPress REST API and secure WordPress.com connection several years ago. Modern Jetpack installations don’t require XML-RPC.

Will disabling XML-RPC break the WordPress mobile app?

The current WordPress mobile app uses the REST API, not XML-RPC. If you’re using a very old version of the app, update it. Modern versions work fine with XML-RPC disabled.

Should I delete xmlrpc.php?

No. Deleting core WordPress files causes problems and the file will return with the next WordPress update. Instead, block access to it using the methods above.

Is XML-RPC the same as the REST API?

No. They’re different systems that accomplish similar goals. XML-RPC is the old method (2003). The REST API is the modern method (2016). The REST API has better security features and is what WordPress actively develops and supports.

Will blocking XML-RPC stop all brute force attacks?

No. Attackers can still target your regular login page. Disabling XML-RPC eliminates one major attack vector, but you should also implement login protection, strong passwords, and two-factor authentication.

My security plugin says XML-RPC attacks are blocked. Why disable it?

Blocking attacks is good, but preventing the requests from reaching WordPress at all is better. Each blocked attack still consumes server resources. Disabling XML-RPC at the server or CDN level is more efficient.

Conclusion

XML-RPC is a legacy feature that most WordPress sites don’t need. It remains enabled by default for backward compatibility, but for most site owners, it’s simply an attack vector waiting to be exploited.

The recommendation is clear: disable XML-RPC unless you have a specific, confirmed need for it. The process takes minutes, the risk reduction is significant, and the vast majority of sites experience no negative effects.

To disable XML-RPC on your site:

1. Use a security plugin for the simplest solution
2. Or add server-level blocking via .htaccess, nginx, or Cloudflare
3. Verify it’s disabled by visiting /xmlrpc.php directly
4. Monitor for any broken functionality (rare)

Combined with other security measures like strong passwords, two-factor authentication, and regular updates, disabling XML-RPC significantly reduces your site’s attack surface.