XML-RPC es en origen un protocolo genérico: un programa envía una petición XML que nombra un método y sus parámetros, el servidor lo ejecuta y responde en XML. En WordPress toma la forma del archivo xmlrpc.php, en la raíz del sitio. Viene de una época en la que las entradas se escribían en un programa de escritorio, y recoge las antiguas API Blogger, metaWeblog y Movable Type además de los métodos wp.* propios de WordPress.
Para qué sirve hoy XML-RPC
- Publicar a distancia desde una aplicación o una herramienta externa que se autentica con un nombre de usuario y una contraseña.
- Recibir pingbacks, esas notificaciones que envía otro blog cuando te cita (método
pingback.ping). - Hacer funcionar ciertos servicios, en especial Jetpack, cuya conexión con WordPress.com pasa por
xmlrpc.php.
Desde la llegada de la API REST al núcleo, la mayoría de estas necesidades tienen una solución más moderna. Muchos sitios ya no usan XML-RPC en absoluto, aunque sigue activo por defecto.
Los riesgos
La documentación oficial de WordPress cita xmlrpc.php como un objetivo frecuente de los ataques de fuerza bruta: cada llamada de publicación acepta un usuario y una contraseña, sin página que cargar ni cookie. En octubre de 2015, Sucuri describió ataques que usaban el método system.multicall para probar cientos de contraseñas en una sola petición HTTP. WordPress 4.4 limitó esta amplificación: tras un fallo de autenticación, las llamadas siguientes de la misma petición también fallan. Aun así, el método sigue siendo una fuente de carga y un motivo frecuente de bloqueo en los cortafuegos.
Los pingbacks plantean otro problema. Para verificar un pingback, WordPress va a leer la página que dice citarlo, en una dirección facilitada por el remitente. Así, miles de sitios pueden usarse como relé de un ataque DDoS contra una misma víctima sin haber sido hackeados.
En WordPress: cerrar o limitar XML-RPC
Un punto que suele malinterpretarse: el filtro xmlrpc_enabled no desactiva XML-RPC. Su documentación precisa que solo corta los métodos que exigen autenticación, no los pingbacks. Según tu uso:
- Ningún uso: bloquea
xmlrpc.phpen el servidor o en el CDN (bloque<Files "xmlrpc.php">en Apache,location = /xmlrpc.php { deny all; }en Nginx). Es el único método que evita también la carga de PHP. - Jetpack: el mismo bloqueo, con una excepción para las direcciones IP que publica Jetpack.
- Publicación a distancia: conserva el archivo, retira
pingback.pingcon el filtroxmlrpc_methodsy usa contraseñas de aplicación, que se pueden revocar una a una.
Después del cambio, abre /xmlrpc.php en una ventana privada: la respuesta debe ser 403 o 404. Nuestro artículo XML-RPC en WordPress: riesgos, usos y desactivación compara los métodos en detalle. Si mantienes XML-RPC, la autenticación de dos factores en las cuentas que publican reduce el valor de las contraseñas robadas.
El módulo de refuerzo de seguridad de WP Masquerade trata XML-RPC en su versión gratuita: un primer nivel retira los métodos de pingback y el siguiente hace que xmlrpc.php responda con un error 404, avisando de que Jetpack y algunas aplicaciones dejarán de funcionar. Como el bloqueo lo hace WordPress, PHP sigue trabajando: una regla de servidor o de CDN elimina también esa carga. Las peticiones a la dirección cerrada se cuentan como una trampa para bots.