« XML-RPC is used in WordPress as an API for third-party clients such as WordPress mobile apps, popular weblog clients like Windows Writer and popular plugins such as Jetpack. »

On retrouve cette information sur le site officiel WP : http://codex.wordpress.org/XML-RPC_Support

Cette API est aussi utilisé pour les retroliens (référencement croisé des blogs). « Le mécanisme incriminé fonctionne de la façon suivante :
    un blogueur écrit un article sur son site ;
    un second blogueur mentionne l'article sur son propre site ;
    si la fonctionnalité est activée, un commentaire est automatiquement effectué sur le site original via une requête XML-RPC, appelée « ping ». »
(source : http://www.cert.ssi.gouv.fr/site/CERTFR-2014-ACT-013/CERTFR-2014-ACT-013.html)

Évidemment, cette fonctionnalité, activée par défaut depuis WP 3.5 et qui ne nécessite aucune authentification peut être abusée pour conduire un DDoS : « Le service XML-RPC étant activé par défaut et ne requérant pas d'authentification, l'envoi massif de requêtes falsifiées provenant soi-disant d'un site A vers un site B, conduit le site B à effectuer en retour des requêtes vers le site A. Employé à grande échelle, ce mécanisme consomme de la bande passante et de la ressource sur les serveurs Web des deux sites, visant à saturer le service du site cible. »

C'est pas nouveau, c'est connu depuis 2012 et une grande vague d'attaques a eu lieu tout au long de 2014 mais surtout au début (cf : http://blog.sucuri.net/2014/03/more-than-162000-wordpress-sites-used-for-distributed-denial-of-service-attack.html).

Ne pas oublier également qu'à chaque requête, le code contenu dans wp-cron.php est exécuté (logique des cron WP ;) ). Donc le blog WP utilisé comme intermédiaire pour l'attaque peut être DoS involontairement par l'attaquant.

Notez que si le blog WP intermédiaire utilisé par l'attaquant est limité en RAM (ou que trop de programmes sont en cours d'exécution), le spawn de nouveaux processus Apache et la surcharge MySQL peuvent entraîner, à terme, des OOM (Out-Of-Memory) et conduire le noyau a exécuté l'OOM-killer pour tenter de revenir à la normal. Exemple :
« 23.95.12.234 - - [03/Jan/2015:12:03:29 +0100] "POST /xmlrpc.php HTTP/1.0" 500 539 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
23.94.17.146 - - [03/Jan/2015:12:03:35 +0100] "POST /xmlrpc.php HTTP/1.0" 500 539 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
23.94.17.146 - - [03/Jan/2015:12:03:44 +0100] "POST /xmlrpc.php HTTP/1.0" 500 539 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
23.94.17.146 - - [03/Jan/2015:12:03:19 +0100] "POST /xmlrpc.php HTTP/1.0" 500 539 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
23.94.17.146 - - [03/Jan/2015:12:03:33 +0100] "POST /xmlrpc.php HTTP/1.0" 500 539 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
[...]
Jan  3 12:04:52 localhost kernel: apache2 invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0 »

Plusieurs solutions de mitigation sont possibles : désactiver la fonctionnalité des retroliens uniquement, désactiver intégralement XML-RPC, rendre inaccessible (HTTP 403)  xmlrpc.php, fail2ban, ... Ça dépend de votre usage de XML-RPC.

Dans mon cas, je n'utilise pas JetPack (apparemment un truc trop cool pour lier votre blog à wp.com...), je n'utilise pas d'éditeur distant pour écrire/modifier mes billets de blog et je sais vivre sans retroliens (je n'en ai jamais eu beaucoup, je sais lire les referrer et utiliser les fonctionnalités des moteurs de recherche comme « links: » chez Google si voir les liens vers mon blog m'intéresse et xmlrpc.php était en 403 au début de mon blog sans aucun soucis). J'ai donc décidé de (ceinture et bretelles) : désactiver la fonctionnalité PingBack dans l'admin (Réglages -> Discussion -> décocher « Autoriser les liens de notifications depuis les autres sites (notifications par pings et rétroliens) »), désactiver complètement XML-RPC depuis functions.php de mon thème (voir ressource linkée par ce shaarli) et demander à Apache de répondre 403 quand on viendra lui parler de cette page (on déporte ainsi intégralement la charge de WP vers Apache qui, moins gourmand, tiendra beaucoup mieux le choc en cas d'attaque)  :
<FilesMatch "(wp-config|xmlrpc).php">
    order allow,deny
    deny from all
</FilesMatch>