Looking for a fast way to switch off XML-RPC in WordPress? But before you do, think about why you’re doing it.

You’re likely to have a slew of other inquiries as well:

  • What is xmlrpc.php?
  • How big of a security risk is it?
  • Does disabling xmlrpc.php automatically resolve the threat?

We’ll answer all of these questions and more in this post.

TL;DR: Turning off XML-RPC on WordPress isn’t a viable option. Hackers would finally discover a new weakness to hack. Instead, to keep bots and malicious IPs out, we suggest installing a strong WordPress firewall.

Is your website being hacked because of XML-RPC?

No, no, and no.

Hackers are attempting to gain access to your website by attempting different usernames and password combinations. But don’t worry; your website hasn’t yet been compromised.

This has happened on almost every place we’ve visited. The odds of your site being compromised as a result of this are slim if you used strong passwords. Just about 5% of the 10,000+ compromised sites we’ve seen have been hacked as a result of such attacks.

However, such attacks, also known as brute force attacks, deplete server resources. Even if your login and admin pages are secured, these attacks bypass them completely, causing the server to become overloaded.

What is XML-RPC?

WordPress has a function called XML-RPC that allows data to be transferred between WordPress and other systems. While REST API has largely replaced it, it is still present in installations for backward compatibility.

Third-party apps can publish content on your WordPress website using XML-RPC. For example, XML-RPC enables you to publish a post from your smartphone using the WordPress mobile app.

That isn’t all it can do, however. It was also used to connect with other blogging sites through WordPress. It made trackbacks and pingbacks possible.

Even an earlier version of the Jetpack plugin ran on it.

It’s usually used by WordPress to bind to the WordPress mobile app. If you’ve used the WordPress mobile app before, you’ll recall having to use XML-RPC.

The strangest part of this whole situation is that WordPress no longer uses XML-RPC. WordPress hasn’t used the old codebase since releasing its own REST API.

The only reason you do have the xmlrpc.php file in your WordPress installation is for backward compatibility. To put it another way, it’s just for websites that are already using an Outdated edition of WordPress!

If this is the case, we strongly advise you to back up your website and update your WordPress core files, themes, and plugins right away. Hackers attempting to bind to xmlrpc.php face much greater security threats than staying on older versions of WordPress.

The bottom line is that if your WordPress version is higher than 4.7, you can safely disable XML-RPC. If you’re using Jetpack, it won’t be affected by this. However, while disabling XML-RPC is a perfectly safe action in and of itself, it does little to protect your site from hackers.

Why hackers attack XML-RPC

If you’ve ever used the WordPress mobile app, you’ll recall that before you can make adjustments, you must first log in to your website. This login is now accomplished by submitting your credentials to the xmlrpc.php script, which validates and authenticates your credentials.

Hackers essentially try to do the same thing: submit the xmlrpc.php script access credentials to your website. The most serious danger is if your password is poor and easily guessed. When this happens, XML-RPC becomes a security problem.

Otherwise, you’re looking at the prospect of an overloaded server—which isn’t ideal but is easily remedied with a firewall.

OAuth tokens are a form of authentication used by WordPress 4.7 and higher versions that use the REST API to communicate with external applications. OAuth is a safe way to link to a third-party app. The method of using the username and password directly in XML-RPC is not at all reliable.

A hacker or a bot will submit different usernames and passwords to bind to xmlrpc.php before they guess the right one if they have enough time.

This is called a brute force attack.

Another big security flaw with XML-RPC is that it was used for pingbacks, which are WordPress notifications that someone has connected to your content. The danger is that a hacker could flood your site with pingbacks.

A DDoS attack will overburden your server, deplete server resources, and result in your website being suspended by your web host!

This feature was also replaced by the REST API. So, if pingbacks are essential to you, you can safely disable XML-RPC on WordPress.

If you’re worried that you’re one of the 5% whose website has been compromised, run our free malware scanner right now to rule out the possibility.

Should you disable XML-RPC?

We strongly warn against disabling XML-RPC.

What is the explanation for this?

Simply put, disabling the PHP file will not help you. Hackers and bots are not stopped by disabling XML-RPC. It simply directs their attention to wp-login.php, where brute force attacks can be carried out.

Second, since the plugin must load in order to block the request, it will slow down your website.

Protecting your website is more critical, and if you’ve read this far, you can probably guess that we recommend installing a firewall. That old chestnut, indeed.

How to disable XML-RPC on WordPress

You can disable WordPress XML-RPC in two ways, as with everything else in WordPress:

  • Using a plugin
  • Without a plugin

In most instances, we suggest using a plugin to accomplish almost every mission on WordPress. Changing code manually in the WordPress backend can be catastrophic. Even though we don’t recommend either approach in this situation, we’ll show you how to do both anyway.

Before you do something, remember to proceed with caution and make backups of your website.

Step 1: Check if XML-RPC is enabled on your website

Even if xmlrpc.php was included with your WordPress installation, that doesn’t mean it’s still around. Before you try to uninstall XML-RPC on your website, make sure it’s still working.

Use the WordPress XML-RPC Validation Service to validate your XML-RPC requests. This app will search your website for xmlrpc.php and notify you if it is enabled.

Step 2: Disable XML-RPC on your website

It’s finally time to deactivate XML-RPC on your WordPress account.

We’ll show you how to do it in two separate ways. Although we don’t suggest disabling the file at all, if you’re dead set on doing so, we’ll also allow you to use the plugin.

Option A: Using a plugin

You can use a number of plugins to disable XML-RPC on your website. The REST XML-RPC Data Checker plugin is recommended.

Keep in mind that loading the plugin to block the request will cause your website to slow down. Also, instead of targeting the wp-login.php file, the hackers would target it.

As a consequence, in terms of defense, this will accomplish nothing. Instead, we recommend downloading MalCare’s advanced firewall plugin if you want real security.

Go to Settings > REST XML-RPC Data Checker after installing the plugin.

Then choose XML-RPC from the drop-down menu.

The API interface, the ability to format WordPress messages, pingbacks, and trackbacks can all be turned off. You may also add a trusted user who can still use XML-RPC or a list of trusted IP addresses that will not be blocked as an added benefit.

Fast and to the point! However, fiddling with the REST tab is not recommended. Simply leave the default settings in place.

Option B: Without a plugin

This is the very worst choice available. We strongly advise you to skip ahead to the next segment, where we teach you how to actually defend against XML-RPC attacks.

If you insist on manually disabling XML-RPC, we strongly advise you to first make a complete backup of your website.

You can use one of two ways, depending on the type of server your website is using:

Using.htaccess, disable WordPress XML-RPC.

Copy and paste the following code into your .htaccess file:

# Block WordPress xmlrpc.php requests
<Files xmlrpc.php>
order deny,allow
deny from all
allow from xxx.xxx.xxx.xxx
</Files>

In the 5th line ‘allow from xxx.xxx.xxx.xxx’, replace the x’s with your IP address, if you would like to retain XML-RPC from a particular IP. You can easily erase this line if you don’t want to use it.

You can connect to your server using cPanel or FTP if your website is hosted with Apache. You’ll be able to use your .htaccess file in either case.

Using the. config file, disable WordPress XML-RPC.

You can add the following code to the Nginx. config file for sites hosted on Nginx:

location ~* ^/xmlrpc.php$ {
return 403;
}

Alternatively, you may simply request that your web host disable XML-RPC for you.

Using a filter, disable WordPress XML-RPC

Alternatively, every plugin may have a filter added to it:

add_filter('xmlrpc_enabled', '__return_false');

You can do the same thing with the theme functions file, but writing a plugin is a much better practice. You may also use this approach regardless of the type of server you have.

Again, none of these solutions are especially useful, and making manual changes is never a good idea. So, if you must do it, make sure you have a WordPress backup ready in case things go wrong.

How to prevent XML-RPC attacks

This is the most critical part of the post, and it’s also the longest. As a result, we decided to break this down into some actionable measures that you can take to protect your website from XML-RPC attacks.

Step 1: Check if your website is already hacked

It’s unlikely that your website has been compromised yet.

But, just in case, you can double-check. If your website has been hacked, you must first delete the malware, otherwise disabling XML-RPC would be pointless.

Using MalCare’s FREE malware scanner is the easiest way to determine whether or not your site has been compromised. MalCare’s scanner is simple to install and use, and it can detect even unknown malware on a website in seconds.

All you have to do if MalCare warns you about a compromised site is click the ‘Autoclean’ button.

Step 2: Install a WordPress Firewall

This is the proper method for dealing with XML-RPC vulnerabilities. Use a WordPress firewall that can detect and block bots attempting to link to xmlrpc.php.

Disabling the file has no impact. The next move for hackers is to try to hack wp-login.php.

The only issue is that firewalls are normally enabled too late. When a hacker attempts to gain access by linking to xmlrpc.php or wp-login.php, the entire WordPress site is loaded.

That’s why we suggest MalCare’s advanced firewall, which can:

  • Before your website loads, protect it from bots and hackers.
  • Like Cloudflare, it does not slow down the loading pace of your website.
  • It learns from a network of 250,000+ websites it protects to continually update a database of malicious IPs.

If your website is covered by MalCare, bots and hackers may receive a 403 error when attempting to link to XML-RPC or WP-Login. A mistake like this will easily put a hacker off from continuing.

Why do people recommend you disable XML-RPC?

There are many explanations for this. Let’s take a closer look at each one so you can see why everyone (yes, even that WordPress management blog) suggests this course of action. (Even though it is just a Band-Aid solution.)

Many of our readers (including yourself) want to disable XML-RPC on their WordPress website because they have encountered server resource issues. You may have seen a lot of hits to the xmlrpc.php file in your logs.

Perhaps you’re a Jetpack user who ran into a configuration error when downloading the plugin. You then looked for this strange-sounding file and read a lot of articles about how it was a security flaw.

Why You Shouldn’t Do This

Blacklist IP addresses

You might believe that manually blocking IPs is a good way to keep hackers out. In fact, many security “gurus” would agree with this. However, it is ineffective. If you block one IP address, a brute force bot can simply start attacking your site using another IP address.

Deleting XML-RPC

Remove the xmlrpc.php file from your WordPress installation at all costs. It’ll fully destroy your site, and even if it doesn’t, the file will reappearance the next time you update WordPress.

So, what’s next?

It’s not a one-and-done situation when it comes to WordPress protection. Yes, installing a firewall is a good place to start, but we also suggest conducting a complete WordPress security audit to see what else you can do.

If you’ve already built MalCare, the intuitive dashboard contains a wealth of recommendations. Simply run a security scan and follow the on-screen instructions.

As you’ll see, hardening the protection of your WordPress website is a smart idea. Again, simply follow the instructions to complete the task in a few quick clicks.

Another critical element of security is keeping updated at all times.

If a new WordPress vulnerability is found, you must be aware of it and take preventative steps before it affects your website.