xmlrpc.php in WordPress: Guide to Security, Risks & Management

All wordpress installations have a file named xmlrpc.php silently present in the root directory. To the majority of site owners, it begs the question, what is that? Is it harmful, and must it be eliminated? This tutorial is a de facto sheet on the information you need to know about xmlrpc.php: what it is, what it is not and what security vulnerability it presents and how to control or disable it so as to keep your WordPress safe.

This file is not only an academic exercise to understand. It has been used in real-world attacks on millions of WordPress sites and its misuse, by keeping it open when not needed or by blocking legitimate functionality, can be disastrous to the security and performance of your site.

What is xmlrpc.php?

xmlrpc.php is a core WordPress file that allows remote communication between your WordPress site and external applications. It uses the XML-RPC protocol, which is a standard that codes commands using XML and sends them via HTTP, enabling third-party tools to communicate with your WordPress site without directly accessing the admin dashboard.

In a real-world scenario, it is a gateway. XML-RPC was a traditional channel through which a mobile application, a desktop blogging client, or an external service could create a post, upload a file or grab content on your site.

A Brief History

XML-RPC is an older technology than web APIs. In the late 1990s, distributed system communication was an essential need for web applications, and XML-RPC became one of the most popular solutions that facilitated the use of remote procedures between platforms.

WordPress integrated XML-RPC to allow remote publishing and cross-platform interaction. Early functionality it powered included:

• Remote post publishing: Mobile apps and desktop clients could create, edit, or delete posts without logging into the web dashboard
• Trackbacks and pingbacks: These features allowed blogs to notify each other when they linked to a post, fostering the early blogging community
• Plugin integrations: Plugins like Jetpack relied on XML-RPC for syncing data and enabling advanced features

Initially, XML-RPC was disabled by default. WordPress 2.6 added a dashboard toggle to enable or disable it. Then, with the release of WordPress 3.5 and the introduction of the official WordPress mobile app, XML-RPC was enabled by default, and the dashboard toggle to disable it was removed entirely. Since then, every WordPress site has had xmlrpc.php active unless deliberately disabled.

Why xmlrpc.php Is a Legacy Component

The introduction of the WordPress REST API, integrated into WordPress core with version 4.7, fundamentally changed how WordPress communicates with the outside world. The REST API is faster, more flexible, and far more secure than XML-RPC, and it has replaced XML-RPC as the standard for virtually all external integrations.

WordPress mobile application, desktop customers, Jetpack, and other contemporary devices are already using the REST API rather than XML-RPC. This renders xmlrpc.php an obsolete endpoint, a fossil left in WordPress only to maintain backward compatibility with archaic systems and older integrations.

xmlrpc.php vs. the REST API

The two protocols differ significantly in how they handle data, authentication, and security:

Feature	xmlrpc.php (XML-RPC)	REST API
Data Format	XML	JSON
Protocol	XML-RPC over HTTP	RESTful HTTP
Authentication	Username/Password with every request	OAuth, Application Passwords
HTTP Methods	POST only (all calls)	GET, POST, PUT, DELETE
Caching	Not cacheable (all POST)	Cacheable (GET requests)
Extensibility	Limited	Highly extensible
Security	Vulnerable to brute-force/DDoS	Stronger authentication, rate limiting
Default Status	Enabled since WordPress 3.5	Core feature since WordPress 4.7

A key architectural difference is that REST APIs are modeled after HTTP itself, leveraging HTTP verbs, status codes, and content types. XML-RPC, by contrast, ignores HTTP semantics, all XML-RPC calls are HTTP POST, which means they cannot benefit from HTTP caching infrastructure, and the target server must process every call. The REST API is also client-independent and offers far greater scope, covering everything from anonymous read access to administrative functionality.

Security Risks of xmlrpc.php

The combination of always-on status, credential-based authentication, and no built-in rate limiting makes xmlrpc.php one of the most commonly exploited entry points in WordPress security. There are three primary attack vectors:

1. Brute-Force Amplification via the system.multicall

This is the most dangerous and commonly exploited vulnerability. XML-RPC supports a method called system.multicall, which allows multiple procedure calls to be bundled into a single HTTP request.

An attacker can craft a single HTTP POST request that contains hundreds or even thousands of username and password combinations. Because each bundled call attempts authentication independently, the attacker effectively tests hundreds of passwords in a single request, all while generating only one entry in your server access logs.

This is what makes it so dangerous: standard security measures focus on /wp-login.php and count individual failed login attempts. XML-RPC bypasses these defenses entirely. Security researchers have demonstrated that the system.multicall method enables up to 500x brute-force amplification compared to standard login attacks.

Additionally, unlike the REST API, which uses OAuth tokens for authentication, xmlrpc.php sends the username and password with every single request. This means credentials are exposed repeatedly, increasing the risk of interception, especially over unencrypted connections.

2. DDoS Amplification via Pingback

The pingback feature, designed to let blogs notify each other of link references, can be weaponized to conduct Distributed Denial of Service (DDoS) attacks against third-party targets.

How the attack works is in the following way: a hacker sends a forged pingback request to thousands of legitimate XML-RPC-enabled WordPress sites. In the request, the attacker designates the victim website as the “source URL.” When a pingback is received, each WordPress site will automatically look to validate the link by making an HTTP request to the server of the victim. When thousands of WordPress websites do so in unison, the web traffic can overwhelm the server of the victim and even take it down.

This makes innocent WordPress websites unwitting participants in an attack, consumes resources on your server, links your IP address with bad traffic, and puts the actual attacker into the shadows to a large extent.

3. Origin IP Disclosure

Pingback requests are made server-side, meaning they bypass CDN and proxy layers like Cloudflare. This creates a mechanism for attackers to discover your real server IP address, even when your site is protected behind a Web Application Firewall (WAF) or reverse proxy. Once the real IP is exposed, attackers can target your server directly, circumventing CDN-level protections entirely.

4. Additional Vulnerabilities

Beyond these three primary vectors, xmlrpc.php also introduces risks of:

• Cross-Site Port Attacks (XSPA): Attackers can use XML-RPC requests to probe internal network infrastructure and services
• Remote Code Execution (RCE): In certain configurations, vulnerabilities in XML-RPC handling can allow unauthorized code execution on the server
• Resource Exhaustion: Repeated or complex XML-RPC calls can overload server resources, particularly in shared or resource-limited hosting environments
• Malware Injection: Recent security research has identified malware campaigns specifically targeting sites with XML-RPC enabled, allowing attackers to make unauthorized modifications without logging into the WordPress system

How to Check If xmlrpc.php Is Active

Before taking action, verify whether XML-RPC is currently enabled on your site. There are three methods:

Navigate to https://yourdomain.com/xmlrpc.php in your browser:

• If you see “XML-RPC server accepts POST requests only” it is enabled
• If you see a 403 or 404 error, it is disabled or blocked

Command Line (cURL)

Run the following command in a terminal, replacing yourdomain.com with your actual domain:

curl -d "system.listMethods" https://yourdomain.com/xmlrpc.php

If you receive a structured XML response listing available methods, XML-RPC is active.

Online Validator Tools

Several free online XML-RPC validator tools allow you to enter your site’s URL and check whether the endpoint responds to XML-RPC requests. These tools are useful for non-technical users who prefer not to use the command line.

Should You Disable xmlrpc.php?

For the vast majority of WordPress sites, yes, xmlrpc.php should be disabled.

The reasoning is straightforward: the REST API now handles everything XML-RPC previously did, with better security, better performance, and broader compatibility. Keeping XML-RPC active provides attackers with an additional attack surface while delivering no functional benefit for modern setups.

When You Might Need to Keep It Enabled

There are a small number of legitimate use cases where keeping XML-RPC active may be necessary:

• You use a legacy desktop blogging client (such as Windows Live Writer or MarsEdit) that does not support the REST API
• You have older plugin integrations that explicitly require XML-RPC and cannot be updated
• You are using an older version of Jetpack or a custom application that was built against the XML-RPC API and cannot be migrated

In these cases, disabling XML-RPC entirely would break the dependent functionality. The better approach is to restrict access to specific IP addresses rather than leaving it fully open.

How to Disable xmlrpc.php

There are multiple methods to disable XML-RPC depending on your technical comfort level, hosting environment, and specific requirements.

Method 1: Using a WordPress Security Plugin (Recommended for Most Users)

The easiest and safest approach for most site owners is to use a dedicated WordPress plugin.

Option A: Dedicated XML-RPC Disable Plugin

1. From your WordPress dashboard, go to Plugins → Add New
2. Search for “Disable XML-RPC” (by Philip Erb) or “Disable XML-RPC-API”
3. Click Install Now and then Activate
4. The plugin immediately applies a WordPress filter to reject all XML-RPC requests

The “Disable XML-RPC” plugin works by using the built-in WordPress filter xmlrpc_enabled set to __return_false. Once activated, no further configuration is needed.

Option B: Full-Featured Security Plugins
Plugins like Solid Security, Wordfence, or Sucuri Security include XML-RPC management as part of a broader security suite. In Solid Security, for example, navigate to Security → Settings → Advanced → WordPress Tweaks, find the XML-RPC settings, and select Disable XML-RPC.

Method 2: Blocking via .htaccess (Apache Servers)

Blocking at the server level is the most efficient approach because requests are stopped before WordPress loads any PHP code at all. This reduces server load in addition to blocking attacks.

Access the .htaccess file in your WordPress root directory (the same folder containing wp-config.php). Always back up the file before making any changes. Add the following code block:

For Apache 2.2 and earlier:

<Files xmlrpc.php>
    order deny, allow
    deny from all
</Files>

For Apache 2.4+:

<Files "xmlrpc.php">
    Require all denied
</Files>

Save the file and upload it back to your server.

Method 3: Blocking via Nginx Configuration

For sites running on Nginx, add the following directive to your server block configuration file:

location = /xmlrpc.php {
    deny all;
}

After adding this block, reload or restart Nginx for the changes to take effect.

Method 4: PHP Filter in functions.php (Advanced)

If you prefer a code-based approach that doesn’t rely on plugins or server configuration files, you can add a filter directly to your active theme’s functions.php file or via a code snippet plugin:

add_filter('xmlrpc_enabled', '__return_false');

This tells WordPress internally to reject all XML-RPC requests. Note that this method disables XML-RPC at the WordPress application level rather than at the server level, so the request still reaches PHP before being rejected.

Method 5: Restrict Access by IP (When You Need Partial Access)

If you need XML-RPC enabled for specific services but want to block general access, you can whitelist specific IP addresses in your .htaccess file. Replace YOUR.IP.ADDRESS.HERE with the actual IP you want to allow:

<Files xmlrpc.php>
    order deny,allow
    deny from all
    allow from YOUR.IP.ADDRESS.HERE
</Files>

This approach maintains necessary functionality while preventing unauthorized access from other IPs.

What Breaks When You Disable xmlrpc.php

Understanding the potential impact before disabling is important. Here is what may stop working:

• Legacy desktop blogging clients that use the MetaWeblog or XML-RPC API.
• Some older Jetpack features that haven’t been fully migrated to the REST API (though modern Jetpack versions primarily use the REST API).
• Remote publishing workflows built on XML-RPC integrations.
• Trackbacks and pingbacks, though many sites already disable these due to spam.
• Third-party applications built against the WordPress XML-RPC API.

Most modern tools and services will be completely unaffected by disabling XML-RPC, as they already communicate via the REST API.

Troubleshooting After Disabling

Remote publishing tool not connecting?
Check whether the tool requires XML-RPC specifically. If so, either re-enable XML-RPC temporarily, restrict it to your IP, or migrate to a REST API-compatible tool. For .htaccess changes, ensure the syntax is correct, even a small error can cause the site to go down.

Site performance issues after re-enabling XML-RPC?
Check your server’s access logs for abusive request patterns to xmlrpc.php. Consider implementing rate limiting at the server or WAF level, or use a security plugin that includes request throttling.

Security plugin not blocking effectively?
If you’re using a plugin-based disable method and still seeing XML-RPC requests in your logs, switch to a server-level block via .htaccess or Nginx configuration. Server-level blocking stops requests before they reach PHP, making it both more secure and more efficient.

Best Practices for WordPress Security Around xmlrpc.php

Even after disabling XML-RPC, a secure WordPress site requires a multi-layered approach:

• Disable xmlrpc.php unless you have an explicit, verified need for it, most modern integrations use the REST API
• Use strong, unique passwords and enable two-factor authentication on all admin accounts
• Keep WordPress core, themes, and plugins updated, security patches for known vulnerabilities are regularly released
• Install a reputable security plugin (Wordfence, Sucuri or Solid Security) for ongoing monitoring and defense-in-depth
• Regularly audit installed plugins for unused integrations that may still reference XML-RPC
• Use a Web Application Firewall (WAF) to add a filtering layer for malicious requests
• Monitor your access logs regularly for unusual request patterns targeting xmlrpc.php or /wp-login.php
• Enable SSL/TLS on your entire site, credential exposure over HTTP is significantly worse when XML-RPC transmits usernames and passwords with every request

Conclusion

xmlrpc.php is a legacy component of WordPress that once served a critical purpose in enabling remote communication and cross-platform integration. Today, the WordPress REST API covers all of those use cases with superior security, broader compatibility, and significantly better performance.

For most WordPress site owners, the risk-benefit calculation is clear: XML-RPC introduces multiple high-severity attack vectors, brute-force amplification, DDoS participation, and IP disclosure, while providing no practical benefit on a modern WordPress setup. Security professionals consistently identify XML-RPC as one of the top findings in WordPress penetration tests, and the recommendation across the security community is unambiguous: disable it unless you have a specific, verified need.

Disabling xmlrpc.php takes only a few minutes using any of the methods described above, plugin, .htaccess, Nginx configuration, or PHP filter. The result is a meaningfully smaller attack surface, reduced server load from malicious bot traffic, and one fewer legacy vulnerability for attackers to exploit.

About the writer

Hassan Tahir wrote this article, drawing on his experience to clarify WordPress concepts and enhance developer understanding. Through his work, he aims to help both beginners and professionals refine their skills and tackle WordPress projects with greater confidence.