Enable XML-RPC by default and remove the option

Quite a bit has changed since we introduced off-by-default for XML-RPC. Their code has improved, and it is no longer considered a second-class citizen when it comes to API development, thanks to the work of a large team of awesome contributors. Security is no greater a concern than the rest of core.

There is no longer a compelling reason to disable this by default. It's time we should remove the option entirely.

Turning XML-RPC on by default is fine now that so many people are trying to use the mobile apps to manage their installs, however removing the ability to turn it off may be a bad idea. Security may not be as big of an issue as it was previously, however keeping XML-RPC enabled provides an addition surface for attack. Unless requested by clients I always ensure their XML-RPC is disabled. Many security conscious folk add additional layers of protect for wp-admin, such as moving it or through plugins, but attackers would know the the XML-RPC was always hanging out there ripe for the picking. Humans are not perfect, there will always be the possibility of a bug causing a security hole. Keep the option and limit the risk.

Turning XML-RPC on by default is fine now that so many people are trying to use the mobile apps to manage their installs, however removing the ability to turn it off may be a bad idea. Security may not be as big of an issue as it was previously, however keeping XML-RPC enabled provides an addition surface for attack. Unless requested by clients I always ensure their XML-RPC is disabled. Many security conscious folk add additional layers of protect for wp-admin, such as moving it or through plugins, but attackers would know the the XML-RPC was always hanging out there ripe for the picking. Humans are not perfect, there will always be the possibility of a bug causing a security hole. Keep the option and limit the risk.

I can see what you mean but I disagree the reasoning. There aren't a lot of plugins adding XML-RPC stuff but the do for other things and plugins are a big cause of security issues. Also if you really want to disable it then just remove the xmlrpc.php file because plugins can add methods that are always accessible even when you put xml-rpc off in your settings.

In my honest opinion, it's very dissapointed to see XML-RPC forced on and no way for admin of the site to turn it off from settings (hey! let admins make some decisions in their sites ;)).

It's not only a matter of security to closing some doors that you don't need to use, it's also a matter about saving memory and resources you simply don't need if you don't use XML-RCP never...

Anyway, having a filter to turn it off is fine for me. But the fact is that using the new xmlrpc_enabled only stops from making login, but the XML-RPC server is still running (and responding), and even if you made login previously in the site through XML-RPC and you're still logged in, you can access even if you hook to the filter to turn it off :(

Removing the xmlrpc.php file form installation maybe is a solution, but not a professional one. For example doing that can create a lot of 404 error messages and therefore make Apache access.log grow with no valid reason.

Please, don't leave it this way. What about put the new filter in some other place to make XML-RPC server totally off?? ;)

it's also a matter about saving memory and resources you simply don't need if you don't use XML-RCP never...

For what it's worth, Having XML-RPC enabled or disabled does not increase, nor decrease used system resources on a standard site. It's not a seperate "server", and the load it places on the web server be it enabled, or disabled does not vary. The only way that it can increase system resources if someone is actually using it (by that, I mean logging in with a correct user/password AND posting articles OR uploading media) - and in all cases, it should require less system resources than visiting your blog dashboard.

furthermore, XML-RPC was always "enabled" it simply disallowed logins when it was "disabled", It was still used for Pingbacks and trackbacks, as well as by many plugins for inter-server communication. The changes here are not a significant change in the way it works.

Please open a new ticket if you'd like to discuss removing the feature entirely from core, but know in advance, that's not happening. Your best bet would be to block XML-RPC access through .htaccess directly and watch random plugins break.

Just wanted to let people know, if you want the function disabled, and not just from logging in, but fully disabled, you can filter the class itself. The reason being, someone has already come out with an exploit for this, that turns WordPress xmlrpc.php into a port scanner. My fix was to create a plug-in that uses a similar filter to the one above, but instead of:

add_filter( 'xmlrpc_enabled', '__return_false' );

I changed it to:

add_filter( 'wp_xmlrpc_server_class', '__return_false' );

You can download the plug-in from my site, or you can just add that line of code, to your current themes functions.php file. If the theme updates automatically though, and replaces the file, you will have to add it back every time. This is why I created a stand alone plug-in to address this issue, since it can not only be used to port scan the local server, it can also be used to send false pingback spam to other sites.

Just because I stumbled upon it and read what you're suggesting to later readers: This is not a good idea. When you look at ~/xmlrpc.php, ​then you'll see, what WP calls immediately after allowing to filter the class. Guess what happens when you call

Hi all. More recently there have been concerns about how xml-rpc.php is widely being abused for DDOS (also for brute force attacks, but really gonna focus on the DDOS). A perfectly secured wordpress site with xml-rpc.php enabled can be easily abused to participate in DDOS attacks.

Enabling xml-rpc by default has drastically affected the volume of DDOS abuses through the wp xml-rpc . I understand it is relatively widely used, however, most wp sites (I believe) do not use pingbacks or wp mobile app for the most part. I believe it should be reverted back to disabled by default and have plugins and remote services that rely on this to enable it either automagically upon install or in their installation instructions.

I personally found 1 site I manage that has been abused through xml-rpc.php. Not sure how many are being abused but I can imagine this increasing since xmp-rpc was enabled by default.

While removing this file or blocking it at the server level (or disabling it in php code) works, so many users (likely most) install wp core and do not specifically use xml-rpc.php pingback or features for wp mobile or other. Besides 4.0 is mobile responsive ;)

I suggest again disabling xml-rpc.php by default. While it is not as severe as open DNS resolvers being abused for DDOS amplification attacks, it is still quite a problem that seems has not been given enough attention lately since xml-rpc was set to enabled by default.

Hi all. More recently there have been concerns about how xml-rpc.php is widely abused for DDOS (also for brute force attacks, but really gonna focus of the DDOS). A perfectly secured wordpress site with xml-rpc.php enabled can be easily abused to participate in DDOS attacks.

Pingbacks, despite living in the XML-RPC API, have never respected the enabled/disabled option for XML-RPC in the admin.

That option only applies to XML-RPC methods that check user credentials, but pingbacks/trackbacks are anonymous and thus do not fall under that check.

There are opportunities for the community to write plugins or better documentation on how to block ping/trackback requests either at the PHP level (e.g., by hooking the xmlrpc_call action and dieing for these methods) or the web server/proxy level (e.g., nginx or Varnish). But just disabling XML-RPC by default will not help with the DDOS issues.

Thank you for clarifying. The concern isn't specifically DDOS directed to WordPress sites, but to any site through the WordPress XML-RPC pingback abuse via spoofing the domain of the target of the DDOS. (reflective DDOS). This type of attack effectively targets the spoofed domain, and then in the process can DOS the wordpress sites participating in the DDOS.

Perhaps I would start working on a patch to make checks in WordPress Core on whether pingbacks and XML-rpc is being used by plugins, themes or remote applications. Perhaps rather making a better way to filter legitimate connections to XML-rpc vs. abusive connections using WordPress sites to DDOS others.

There are opportunities for the community to write plugins or better documentation on how to block ping/trackback requests either at the PHP level (e.g., by hooking the xmlrpc_call action and dieing for these methods) or the web server/proxy level (e.g., nginx or Varnish). But just disabling XML-RPC by default will not help with the DDOS issues.

Another thought it entirely removing xml-rpc.php from core and only have it installed when required. Not sure how to implement that but it's worth considering since wp DDOS exploitability and reputation is somewhat on the line.

Do you have any recent information to cite with respect to XML-RPC posing a significant security risk? The article you cited is from March, and since then the WordPress team has responded by hardening WordPress's XML processing.

Because many people, among them the WordPress team's own iOS and Android app teams, depend upon the XML-RPC API being enabled by default, you're asking a lot to revive interest in disabling it. It will help a lot if you bring a compelling, up-to-date argument for how it's posing a significant risk to WordPress sites.

Docs: Clarify documentation for the xmlrpc_enabled filter to better explain that its scope only extends to methods requiring authentication.

When the xmlrpc_enabled filter was initially introduced in [21509], it was effectively intended to replace the `enable_xmlrpc' UI option, which only controlled whether authenticated XML-RPC methods were enabled, such as for publishing actions. This change clarifies the expected behavior and adds information about ways to more granularly control XML-RPC method and request behavior with related hooks.