What Is XML-RPC in WordPress? Why You Should Disable It

modified time: February 19, 2026

On This Page

If you’ve ever run a security scan on your WordPress site — say, using a tool like FunSentry — you may have seen a warning flag next to something called XML-RPC. The recommendation is almost always the same: disable it.

But what exactly is XML-RPC? Why does WordPress include it? And why do security professionals universally recommend turning it off?

In this guide, we’ll break down everything you need to know — and show you three practical methods to disable it today.

What Is XML-RPC?

XML-RPC stands for XML Remote Procedure Call. It’s a protocol that allows external applications to communicate with your WordPress site over HTTP by sending and receiving data formatted in XML.

In simpler terms, XML-RPC is a doorway that lets other software — like mobile apps, desktop editors, or third-party services — interact with your WordPress site without logging into the admin dashboard.

How It Works (Simplified)

External App → sends XML request → yoursite.com/xmlrpc.php → WordPress processes it → sends XML response

For example, an app might send a request to xmlrpc.php asking WordPress to publish a new blog post, retrieve a list of comments, or upload a media file — all without touching the WordPress dashboard.

A Brief History

XML-RPC has been part of WordPress since its early days. It was originally designed to enable:

Remote publishing from desktop apps like Windows Live Writer and MarsEdit
Pingbacks and trackbacks between blogs
Mobile app access via the WordPress mobile app (before the REST API existed)

In WordPress 3.5 (released December 2012), XML-RPC was enabled by default and the option to disable it from the admin dashboard was removed.

This was a reasonable decision at the time. But today, over a decade later, the landscape has changed dramatically.

Why XML-RPC Is a Security Risk

The problem with XML-RPC isn’t what it was designed to do — it’s how attackers abuse it. There are three primary attack vectors.

1. Brute Force Amplification Attacks

This is the most common and dangerous exploit.

With a normal brute force attack against wp-login.php, an attacker must send one HTTP request per password guess. Most security plugins can easily detect and block this pattern.

XML-RPC changes the equation entirely. The system.multicall method allows an attacker to try hundreds or even thousands of username/password combinations in a single HTTP request.

Here’s what that looks like:

<methodCall>
  <methodName>system.multicall</methodName>
  <params>
    <param>
      <value>
        <array>
          <data>
            <value>
              <struct>
                <member>
                  <name>methodName</name>
                  <value><string>wp.getUsersBlogs</string></value>
                </member>
                <member>
                  <name>params</name>
                  <value>
                    <array>
                      <data>
                        <value><string>admin</string></value>
                        <value><string>password123</string></value>
                      </data>
                    </array>
                  </value>
                </member>
              </struct>
            </value>
            <!-- hundreds more attempts packed into this single request -->
          </data>
        </array>
      </value>
    </param>
  </params>
</methodCall>

With one HTTP request, the attacker can test 500+ passwords. Most rate-limiting plugins only count HTTP requests — so they see one request, not 500 login attempts.

This makes XML-RPC brute force attacks orders of magnitude more efficient than traditional login-page attacks.

2. DDoS Amplification via Pingbacks

WordPress’s pingback system uses XML-RPC to notify other blogs when you link to their content. Attackers abuse this by sending pingback requests from thousands of WordPress sites to a single target:

Attacker sends a pingback request to yoursite.com/xmlrpc.php
Your WordPress site makes an HTTP request to the target URL specified in the pingback
The attacker repeats this across thousands of WordPress sites simultaneously
The target receives thousands of requests — a DDoS attack

Your site becomes an unwitting participant in the attack, and the target sees traffic originating from legitimate WordPress sites, making it harder to block.

3. Server Resource Exhaustion

Even without a successful login, XML-RPC requests consume server resources. Each system.multicall request triggers multiple authentication attempts against your database. Under sustained attack, this can:

Slow down your site for legitimate visitors
Increase hosting costs (CPU, memory, bandwidth)
In extreme cases, crash your server

How to Check If XML-RPC Is Enabled on Your Site

Quick Method: Use FunSentry

The fastest way is to run a free scan at www.funsentry.com. The scanner sends a system.listMethods request to your site’s xmlrpc.php endpoint and reports whether it responds — exactly what an attacker would do to check if the door is open.

Manual Method: cURL

You can also check from the command line:

curl -X POST https://yoursite.com/xmlrpc.php \
  -H "Content-Type: text/xml" \
  -d '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>'

If XML-RPC is enabled, you’ll see a long XML response listing all available methods — this means it’s accessible to attackers too.

If XML-RPC is disabled, you’ll get an HTTP 403 (Forbidden), 404 (Not Found), or 405 (Method Not Allowed) response.

3 Methods to Disable XML-RPC

Method 1: Using .htaccess (Apache) — Recommended

This is the most effective approach because it blocks requests at the web server level, before PHP even executes. Add this to your .htaccess file in the WordPress root directory:

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

If you need to allow specific IPs (e.g., Jetpack servers), you can whitelist them:

<Files xmlrpc.php>
  Order Deny,Allow
  Deny from all
  Allow from 122.248.245.244
  Allow from 54.217.201.243
</Files>

Method 2: Using Nginx Configuration

If your server runs Nginx, add this to your server block:

# Block XML-RPC
location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
    return 403;
}

Reload Nginx after making changes:

sudo nginx -t && sudo systemctl reload nginx

Method 3: Using a WordPress Filter (functions.php)

If you don’t have access to server configuration files, you can disable XML-RPC via your theme’s functions.php or a custom plugin:

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

// Also remove the XML-RPC endpoint from the head
add_filter('wp_headers', function($headers) {
    unset($headers['X-Pingback']);
    return $headers;
});

// Remove RSD link from head (advertises XML-RPC availability)
remove_action('wp_head', 'rsd_link');

Important note: The xmlrpc_enabled filter only disables XML-RPC methods that require authentication. The system.listMethods endpoint and pingback functionality may still respond. For complete protection, combine this with Method 1 or 2.

What About Jetpack and the WordPress Mobile App?

This is the most common concern — “Will disabling XML-RPC break anything?”

WordPress Mobile App

The official WordPress mobile app no longer requires XML-RPC. Since 2016, the app has used the REST API (via /wp-json/) for communication. You can safely disable XML-RPC without affecting the mobile app.

Jetpack

Jetpack historically relied heavily on XML-RPC for its connection to WordPress.com. However, Jetpack has been migrating to the REST API for most of its features. If you’re using Jetpack, test after disabling XML-RPC. If any features break, use the IP whitelist approach shown in Method 1.

Other Third-Party Integrations

Some older plugins or services may still use XML-RPC. Before disabling it, check if you’re using:

IFTTT WordPress integrations
Zapier (older WordPress triggers)
Legacy desktop publishing tools

If you’re unsure, disable XML-RPC and monitor your site for a few days. If nothing breaks, you’re good.

XML-RPC vs. REST API: The Modern Alternative

WordPress introduced the REST API in version 4.7 (December 2016). It serves the same purpose as XML-RPC — allowing external applications to interact with WordPress — but does it better:

Feature	XML-RPC	REST API
Data format	XML	JSON
Authentication	Basic auth (username + password in plain text)	OAuth, Application Passwords, JWT
Multiple calls	`system.multicall` (abusable)	Batch requests with proper rate limiting
Discoverability	Undocumented methods	Self-documenting endpoints
Modern app support	Deprecated	Actively maintained
Security	No built-in rate limiting	Supports nonce verification and capability checks

The REST API is the successor to XML-RPC. There is no modern use case that requires XML-RPC and can’t be accomplished through the REST API.

Defense in Depth: Beyond Just Disabling XML-RPC

Disabling XML-RPC is one piece of a comprehensive WordPress security strategy. Here are related hardening steps:

Use strong, unique passwords — Even if XML-RPC is enabled, a 32-character random password makes brute force impractical
Implement Two-Factor Authentication (2FA) — Adds a second layer even if credentials are compromised
Limit login attempts — Use a plugin to block IPs after failed login attempts on wp-login.php
Keep WordPress core, plugins, and themes updated — Patch known vulnerabilities promptly
Monitor HTTP Security Headers — Ensure HSTS, CSP, and X-Frame-Options are properly configured
Restrict REST API user enumeration — Block the /wp-json/wp/v2/users endpoint from unauthenticated access
Run regular security scans — Use tools like FunSentry to catch misconfigurations before attackers do

Summary

Question	Answer
What is XML-RPC?	A legacy protocol that lets external apps communicate with WordPress
Is it still needed?	No — the REST API has replaced it for all modern use cases
What are the risks?	Brute force amplification, DDoS participation, server resource exhaustion
Should I disable it?	Yes, unless you have a specific legacy integration that requires it
Best method to disable?	Block at the web server level (.htaccess or Nginx) for maximum protection

XML-RPC was useful when it was introduced. Today, it’s an unnecessary attack surface on your WordPress site. Disabling it takes less than five minutes and immediately closes one of the most commonly exploited entry points.

This article was written by the FunSentry security research team. FunSentry is a free online WordPress security scanner that performs passive security checks including XML-RPC detection, HTTP Security Headers analysis, plugin vulnerability scanning, and more. Scan your site now to see if XML-RPC is enabled on your WordPress site.

Free Security Scan

Check your WordPress site's security posture — it only takes 30 seconds.

Scan My Site Now