I have tried a couple of go-to plugins, but I still get a response from XML-RPC.

Is there something specific that needs to be done in a multisite installation?

Plugins tested: Disable XML-RPC Pingback and Disable XML-RPC

I have tried a couple of go-to plugins, but I still get a response from XML-RPC.

Is there something specific that needs to be done in a multisite installation?

Plugins tested: Disable XML-RPC Pingback and Disable XML-RPC

• multisite
• xml-rpc

• note that disabling xmlrpc is a very old and out of date security recommendation, and will cause compatibility issues with some programs and plugins, e.g. Jetpack – Tom J Nowell ♦ Commented Feb 28, 2022 at 19:22
• @TomJNowell Isn't is a baseline security best practice to limit attacks? – mmcglynn Commented Mar 1, 2022 at 16:16
• Strictly that means you should disconnect your site from the internet, nor does it mean you should do it, there are tradeoffs and not all are worth it or feasible. The reason turning off XMLRPC is suggested in a lot of places is because a long time ago it wasn't well secured. Since then it's had a lot of work done on it and is much more secure than it was. Disabling it can even cause problems. There are better places to put your time and effort, e.g. sanitising validating and escaping form inputs, keeping plugins up to date, etc. Most people would struggle to find a current XMLRPC exploit. – Tom J Nowell ♦ Commented Mar 1, 2022 at 18:14
• @TomJNowell XML-RPC is almost never used. Any website that I've administered has received thousand of requests to that URL per hour. What is the argument for keeping it active. You site reasons to let it be - what are they? – mmcglynn Commented Mar 2, 2022 at 13:08
• I've already stated several but perhaps that would be a good candidate for a new question to ask on the site. Note that removing the file will not prevent those requests from occurring, attackers do not check xmlrpc is present, or even WordPress, they work on a fire and forget basis, if their payload works then success, otherwise why bother checking – Tom J Nowell ♦ Commented Mar 2, 2022 at 13:56

1 Answer 1

The simplest solution is a rule inside the .htaccess of the installation, if it is an Apache server. The following syntax should support you.

Protect the whole access

# PROTECT xmlrpc.php
<Files xmlrpc.php>
  Order Allow,Deny
  Deny from all
</Files>

Access for several apps

# ACCESS for xmlrpc surface only for different apps
<IfModule mod_setenvif.c>
  <Files xmlrpc.php>
    # blogs
    BrowserMatch "WordPress" allowed
    # poster
    BrowserMatch "Poster" allowed
    # Windows Livew Writer
    BrowserMatch "Windows Live Writer" allowed
    # WP 4 iOS
    BrowserMatch "wp-iphone" allowed
    # WP 4 Android
    BrowserMatch "wp-android" allowed
    
    Order Allow,Deny
    Deny from All
    Allow from env=allowed
  </Files>
</IfModule>

Deactivation via Filter

There is also an option to deactivate the functionality about a filter. Copy the following example in a custom plugin and use it. It is also possible to use it as 'Must Use plugin'. In your case in a Multisite installation, you should the plugin activates as 'Network Wide', about all sites of the network.

add_filter( 'xmlrpc_enabled', '__return_false' );