Desactivar XML-RPC en WordPress y frenar ataques de fuerza bruta

Deshabilitar XML-RPC en WordPress es de esas tareas de seguridad que dan más rendimiento por esfuerzo invertido. Pocas cosas hay tan sencillas y tan efectivas. XML-RPC es una interfaz heredada que permite la comunicación remota con tu web y que, en la práctica, se ha convertido en la puerta de entrada favorita de los atacantes para lanzar ataques de fuerza bruta. Si tu sitio va lento sin motivo aparente, si el consumo de recursos se dispara de pronto o si encuentras cientos de intentos de inicio de sesión en los registros, casi con seguridad estás siendo atacado por ahí. En esta primera parte veremos qué es exactamente XML-RPC, cómo detectar si te están atacando y te dejamos tres métodos probados para desactivarlo de forma definitiva.

¿Qué es XML-RPC y por qué es un riesgo para tu WordPress?

XML-RPC es un protocolo que WordPress trae integrado desde la versión 2.6. Permite la comunicación remota entre tu sitio y aplicaciones externas. Su función original era sencilla: publicar contenido desde la app móvil de WordPress, gestionar entradas desde clientes de escritorio, y de paso implementar los pingbacks y trackbacks entre sitios.

¿Dónde está el problema? En que este protocolo autentica cada petición con usuario y contraseña, y admite múltiples llamadas en una sola solicitud HTTP mediante el sistema system.multicall. Traducido: un atacante puede enviar cientos o miles de combinaciones de credenciales en una única petición. Así esquiva los plugins de limitación de intentos de login, que solo analizan peticiones individuales. Es como poner un portero en la puerta principal mientras el trastero queda abierto.

Los vectores de ataque más habituales vía XML-RPC son:

• Ataques de fuerza bruta amplificada: el atacante prueba miles de contraseñas contra el usuario admin con un consumo mínimo de sus propios recursos.
• Ataques de pingback: utilizan tu sitio como origen de ataques DDoS hacia otros servidores, y el que acaba pagando eres tú, porque el hosting puede llegar a suspender tu cuenta.
• Consumo de recursos: cada petición a xmlrpc.php ejecuta PHP y consulta la base de datos. Saturan el servidor aunque el ataque no tenga éxito.

Salvo que uses aplicaciones muy concretas como Jetpack o la app móvil de WordPress con publicación remota, lo más probable es que no necesites XML-RPC en absoluto. Para nada.

Cómo saber si tu sitio está sufriendo ataques vía XML-RPC

Antes de actuar, conviene confirmar el diagnóstico. No vayas a cerrar una puerta que nadie está intentando abrir. Estas son las señales más claras:

• Tu sitio va lentísimo, o el hosting te avisa de un consumo anormal de CPU sin causa aparente.
• El archivo access.log de tu servidor muestra miles de peticiones POST a /xmlrpc.php en poco tiempo.
• Recibes correos de usuarios bloqueados, o tu plugin de seguridad registra intentos de login constantes.

Puedes verificarlo con un comando simple vía SSH o consultando el log desde cPanel o Plesk:

También hay herramientas online que permiten comprobar si xmlrpc.php responde en tu dominio. Si al probarlo obtienes un mensaje tipo «XML-RPC server accepts POST requests only», el protocolo está activo y expuesto.

Desactivar XML-RPC WordPress: 3 métodos probados (código, plugin y .htaccess)

Llegados a este punto, tienes tres caminos para cerrar esta puerta, ordenados de menos a más restrictivo:

1. Filtrado por código: añadir un filtro en el archivo functions.php de tu tema hijo que devuelve un error en todas las autenticaciones XML-RPC. Es limpio y sobrevive a actualizaciones de plugins.
2. Plugin de seguridad: soluciones como Wordfence o el específico Disable XML-RPC permiten desactivar el protocolo con un clic. Ideal si prefieres no tocar código.
3. Bloqueo a nivel de servidor con .htaccess: el método más contundente. Apache rechaza las peticiones antes de que WordPress cargue, con el consiguiente ahorro de recursos del servidor.

Cada método tiene sus ventajas y sus casos de uso. En la segunda parte de este artículo detallaremos la implementación exacta de cada uno, con fragmentos de código listos para copiar y pegar.

¿Deberías desactivar XML-RPC completamente o solo bloquear métodos?

La respuesta depende de si usas algún servicio que dependa de esta interfaz. Antes de desactivar XML-RPC en WordPress de forma radical, revisa estos puntos:

• Aplicación móvil oficial de WordPress: si la usas para publicar o moderar comentarios, la necesitas activa.
• Jetpack: todo el plugin depende de XML-RPC para comunicarse con los servidores de Automattic. Desactivarlo romperá Jetpack por completo.
• Plugins de publicación cruzada: herramientas como Blog2Social o algunas integraciones con IFTTT y Zapier pueden utilizarlo.
• Publicación remota: si escribes desde apps como Open Live Writer o editores de escritorio.

Si ninguno de estos casos te aplica (y en la mayoría de sitios actuales no aplica), la desactivación completa es lo mejor. ¿Que necesitas conservar alguna funcionalidad concreta? Entonces puedes desactivar solo los métodos conflictivos. Por ejemplo, para bloquear únicamente pingbacks y trackbacks, que son el origen de la mayoría de ataques de amplificación:

add_filter('xmlrpc_methods', function($methods) { unset($methods['pingback.ping']); unset($methods['pingback.extensions.getPingbacks']); return $methods; });

Esta vía intermedia mantiene la API operativa para lo que necesitas y elimina el vector de ataque más explotado. Si en cambio optas por el bloqueo total, el filtro más sencillo es este:

add_filter('xmlrpc_enabled', '__return_false');

Complementa cualquiera de los dos enfoques con el bloqueo a nivel de servidor descrito en la sección anterior. Así evitas incluso que PHP se cargue al procesar peticiones maliciosas. Menos trabajo para el servidor. Siempre.

Comprobaciones posteriores: cómo verificar que XML-RPC está desactivado

Una vez aplicado el método elegido, verifica que funciona antes de dar por cerrado el trabajo. No confíes a ciegas en que «ya está». Estas son las comprobaciones esenciales:

1. Prueba manual con curl: ejecuta curl -X POST https://tudominio.com/xmlrpc.php -d "<methodCall><methodName>system.listMethods</methodName></methodCall>". Si está bien bloqueado deberías recibir un error 403, 406 o una respuesta vacía. Nunca la lista de métodos.
2. Acceso directo en el navegador: visita https://tudominio.com/xmlrpc.php. El mensaje normal de WordPress es «XML-RPC server accepts only POST requests». Si recibes un 403 de Apache o nginx, el bloqueo del servidor está activo.
3. Verifica la respuesta del filtro: si usaste xmlrpc_enabled, la petición POST devolverá «XML-RPC server not running», señal de que WordPress la rechaza internamente.
4. Revisa los logs: pasadas 24-48 horas, consulta /var/log/apache2/access.log o el access log de nginx y busca peticiones a xmlrpc.php. Lo normal es ver solo errores 403 procedentes de bots, y una caída drástica del consumo de CPU. Ese descenso en la gráfica es la mejor confirmación de que lo hiciste bien.

Un matiz: si tu sitio usa Jetpack y lo has conservado, comprueba que la conexión sigue activa en el panel del plugin. En caso contrario, desactivar solo pingbacks es la vía que deberías replantear.

Conclusión: XML-RPC fuera, tu WordPress más seguro

Desactivar XML-RPC en WordPress es, dentro del mundillo de la seguridad, una de las medidas con mejor relación esfuerzo-beneficio que existe. En la mayoría de instalaciones actuales es una interfaz heredada que solo sirve a los atacantes para lanzar fuerza bruta y pingbacks de amplificación sin apenas costo para ellos, pero con un consumo elevado de recursos en tu servidor. Salvo que uses Jetpack, la app móvil oficial o algún servicio de publicación remota, el filtro xmlrpc_enabled combinado con una regla de bloqueo en .htaccess o nginx te ofrece una protección en dos capas: WordPress rechaza la API y el servidor ni siquiera deja llegar las peticiones masivas.

El protocolo completo, en resumen: audita si realmente lo necesitas, aplica el bloqueo, verifica con curl y monitoriza los logs durante los primeros días. Unos minutos de trabajo se traducen en menos intentos de intrusión, menos carga del servidor y un archivo de seguridad más limpio. ¿Prefieres que un profesional lo configure y revise tu instalación de principio a fin? En RedServicio (redservicio.net) encontráis soporte especializado en seguridad y mantenimiento de WordPress para dejar este y otros vectores de ataque cerrados correctamente.