xmlrpc.php in WordPress: What it is and how to disable it

xmlrpc.php in WordPress: What it is and how to disable it

xmlrpc.php is a WordPress core file that allows external applications to communicate with your website remotely. It uses the XML-RPC (XML Remote Procedure Call) protocol, which sends XML-formatted requests over HTTP to perform actions such as publishing posts, managing content through mobile apps, and handling pingbacks.

While xmlrpc.php was useful for early WordPress integrations, it is now unnecessary for most modern websites. Most current tools rely on the WordPress REST API instead, which uses JSON and supports more modern authentication workflows. Attackers target XML-RPC for brute-force logins, system.multicall abuse, and pingback floods that overwhelm servers in a DDoS (Distributed Denial of Service) attack, because it relies on older access methods.

For most WordPress site owners, the safest approach is to disable or restrict xmlrpc.php unless a specific plugin, mobile app, or external service still needs it. This can be done with a security plugin, server rules such as .htaccess on Apache, or a web application firewall.

What is xmlrpc.php in WordPress?

XML-RPC is a feature of WordPress that enables data to be transmitted, with HTTP acting as the transport mechanism and XML as the encoding mechanism. Since WordPress isn’t a self-enclosed system and occasionally needs to communicate with other systems, this was used to handle that job.

The core features that xmlrpc.php enabled were connecting to your site via smartphone, implementing trackbacks and pingbacks from other sites, and some functions associated with the Jetpack plugin.

Let’s say you wanted to post to your WordPress site from your mobile device. You could use the remote access feature enabled by xmlrpc.php to do just that.

Why was xmlrpc.php created and how was it used

The use of XML-RPC dates back to the early days of WordPress, before it was even called WordPress.

Writing and publishing on the internet were much more difficult and time-consuming in the early days of the internet when connections were incredibly slow. At the time, the solution was to create an offline blogging client where you could compose your content before connecting to your blog to publish it. This connection was established using XML-RPC.

XML-RPC was initially disabled by default until WordPress 2.6 added a feature in the dashboard to enable or disable it. Then, XML-RPC was enabled by default with WordPress 3.5 and the introduction of the WordPress mobile app. The option to enable or disable XML-RPC from the dashboard was also removed.

XML-RPC nowadays

In 2015, WordPress core introduced a new REST API for interacting with mobile applications and other platforms. Many developers began to use the new WordPress REST API instead, which effectively replaced XML-RPC.

However, XML-RPC is still enabled in WordPress, and the xmlrpc.php file is still located in the core software directory.

Why you should disable xmlrpc.php

The biggest problem with XML-RPC is the WordPress security concern that arises. The file itself is not malicious, it is a legitimate WordPress core file. The risk comes from how attackers can abuse XML-RPC to target your site with brute-force login attempts, pingback exploitation, system.multicall abuse, and high-volume requests that increase server load.

One common risk is brute-force attacks. Instead of targeting only the standard WordPress login page, attackers can send repeated login attempts through xmlrpc.php using different username and password combinations. In some cases, they can use XML-RPC methods to test many combinations in fewer requests, making the attack harder for basic security tools to detect and block.

Another major issue is DDoS abuse through pingbacks. WordPress pingbacks were designed to notify other websites when your content links to them. However, attackers can misuse this feature to send large numbers of requests to other sites or overwhelm your own server with traffic. This can slow down your website, consume hosting resources, or even take the site offline temporarily.

For this reason, strong passwords and WordPress security plugins are not always enough. If your website does not rely on XML-RPC for mobile publishing, Jetpack, legacy plugins, or remote management tools, disabling xmlrpc.php is one of the easiest ways to reduce your attack surface.

Before disabling it, check whether XML-RPC is active on your site. You can use an XML-RPC validator tool or open https://yourdomain.com/xmlrpc.php in a browser. If you see a message saying that the XML-RPC server accepts POST requests only, the endpoint is likely enabled. If you see an error, block message, or 404 page, XML-RPC may already be disabled or restricted.

Pro tip

Various threats pose risks to your website's security. Safeguarding your website against potential vulnerabilities can be achieved by choosing a dependable WordPress hosting provider. Ensure your website's protection by selecting a secure WordPress host that implements advanced security measures.

How to disable xmlrpc.php in WordPress

There are several ways to disable xmlrpc.php. The best method depends on your hosting setup, technical comfort level, and whether you want to block all access or allow specific trusted services.

1. Disabling xmlrpc.php with a plugin

With a plugin, disabling XML-RPC on your WordPress site is simple.

Simply navigate to the Plugins → Add New section from within your WordPress dashboard. Search for Disable XML-RPC-API and install it. Once you activate the plugin, it will automatically apply the necessary code to turn off XML-RPC.

Keep in mind that other existing plugins may utilize parts of XML-RPC, so disabling it completely could cause a plugin conflict or certain elements of your site to no longer function.

2. Disabling xmlrpc.php manually on Apache

If you prefer not to use a plugin, you can manually block access to xmlrpc.php through your site’s .htaccess file. This method applies to websites running on an Apache server and prevents XML-RPC requests from reaching WordPress.

Do not delete the xmlrpc.php file from your WordPress installation. It is a core WordPress file, and deleting it may cause issues or be reversed during the next WordPress update. Instead, block public access to the file using server rules.

To block xmlrpc.php manually:

  1. Access your website files through your hosting control panel’s File Manager or an FTP client.
  2. Open your site’s root directory, usually named public_html, www, or the folder containing your WordPress files.
  3. Locate the .htaccess file. If you cannot see it, enable the Show hidden files option.
  4. Open the .htaccess file and add the following code:
# Block WordPress xmlrpc.php requests
<Files "xmlrpc.php">
    Require all denied
</Files>
  1. Save the file and test your website to make sure everything works properly.
  2. Visit https://yourdomain.com/xmlrpc.php to confirm that access is blocked.

If a trusted service still needs access to XML-RPC, allow only its IP address instead of blocking everyone:

# Allow xmlrpc.php only from a trusted IP address
<Files "xmlrpc.php">
    Require ip xxx.xxx.xxx.xxx
</Files>

7. Replace xxx.xxx.xxx.xxx with the trusted IP address.

3. Blocking xmlrpc.php with a web application firewall

Another way to disable or restrict xmlrpc.php is to block it with a web application firewall, or WAF. This method is especially useful if your website is receiving many XML-RPC requests, because the firewall can stop malicious traffic before it reaches your WordPress server.

A WAF lets you create rules that block, challenge, or rate-limit requests to:

/xmlrpc.php

For example, you can configure your firewall to block all requests to xmlrpc.php, allow only trusted IP addresses, or apply stricter rules to repeated POST requests. This is helpful against brute-force attempts, pingback abuse, and DDoS-style traffic.

To block xmlrpc.php with a WAF:

  1. Open your hosting security settings, CDN dashboard, or WAF provider account.
  2. Create a new firewall rule.
  3. Set the rule to target requests where the URI path equals /xmlrpc.php.
  4. Choose an action, such as Block, Challenge, or Rate limit.
  5. Save the rule and test https://yourdomain.com/xmlrpc.php to confirm the endpoint is blocked or restricted.

This method is safer for high-traffic attacks than using only a WordPress plugin, because unwanted requests are filtered before WordPress has to process them.

Strengthen your WordPress security beyond xmlrpc.php

Disabling or restricting xmlrpc.php closes one entry point, but a single fix won’t secure a WordPress site on its own. Attackers probe plenty of other targets – login pages, outdated plugins, weak passwords – so harden the whole site once xmlrpc.php is handled.

After managing xmlrpc.php, review your overall WordPress security setup. Start by using strong passwords, enabling two-factor authentication, updating plugins and themes, removing unused extensions, and setting up regular backups. You should also monitor login attempts, scan for malware, and use a web application firewall to filter suspicious traffic before it reaches your site.

Our WordPress security checklist walks through every step, from updating the WordPress core to restricting access to sensitive files, to reduce vulnerabilities, protect user accounts, and stop the most common WordPress attacks.

All of the tutorial content on this website is subject to Hostinger's rigorous editorial standards and values.

Author
The author

Ariffud Muhammad

Ariffud is a Technical Content Writer with an educational background in Informatics. He has extensive expertise in Linux and VPS, authoring over 200 articles on server management and web development. Follow him on LinkedIn.

What our customers say