In reply to Sergey.

Thank you for your reply. Let’s see if I can address the issues you mentioned.

We improved in WordPress 3.4 and 3.5 the capabilities of the XML-RPC and checked the code quality. This included a lot of new unit tests written to be sure that code was correct and things were secure capability wise. Having the need of username/password is still a security problem but it’s also a hard/impossible problem to fix. Based on that, enabling the XML-RPC was something that made sense. It was way more easier to use mobile apps and offline editors. Downside is another entry for hackers to get in. Numbers I got from this year from a host still shows that wp-login.php gets attacked way more then the XML-RPC. The only said part since then was the ability to login multiple times with one request. That is something I should have looked at before XML-RPC got enabled by default.

That sites running on a VPS doesn’t mean a lot. There are sites running faster on a shared hosts then on a VPS. In the end it’s all about the hardware/software and getting everything out of it. I guess with POST pings you mean trackbacks. Though it is in the XML-RPC code, I wouldn’t say that the XML-RPC should be disabled only based on that. But if you don’t need the XML-RPC then blocking it is a good thing to do. It’s your site and you know if you don’t need it. For a host with many clients it’s a different story.

I disagree with the statement that REST API has protection because of needed keys. You can still call it and it will run your PHP code. That same goes for the XML-RPC. The way authentication works is different but there are still database queries happening and both cases caching is a hard thing to do. So it’s still ending up being a DDoS attack with a lot of traffic. I don’t know if the REST API is more secure since it can be accessed with the cookie data and a nonce so that is also a risk.

I’m wondering what the traffic was from WordPress clients. Was it through the XML-RPC or just WordPress sites that got hacked?