xmlrpc.php en WordPress: cómo desactivarlo sin romper nada

Si has mirado alguna vez los registros de tu web, habrás visto una línea que se repite cientos de veces al día: POST /xmlrpc.php. No es un error ni una casualidad. Es uno de los tres o cuatro ficheros que todo escáner automático prueba en cuanto detecta un WordPress, y sigue estando activo por defecto en la mayoría de instalaciones.

La pregunta que nos llega es siempre la misma: ¿lo desactivo o no? La respuesta corta es que en el 90 % de las webs de empresa sí, y no pasa nada. La larga tiene un par de matices que conviene conocer antes de tocarlo, porque hay instalaciones donde desactivarlo rompe cosas que sí usas.

Qué es xmlrpc.php y por qué sigue ahí

xmlrpc.php es una puerta de entrada remota a WordPress. Nació cuando no existía la API REST y hacía falta una forma de que programas externos —la app móvil, un cliente de escritorio, otro blog— publicaran contenido sin pasar por el escritorio. Habla un protocolo antiguo basado en XML: le mandas una petición con un usuario, una contraseña y una orden, y él ejecuta.

Desde WordPress 4.7 existe la API REST, que hace lo mismo mejor y con autenticación moderna. XML-RPC se quedó por compatibilidad: quitarlo del núcleo rompería instalaciones antiguas, así que sigue activo aunque casi nadie lo use.

Por qué lo atacan tanto

Hay dos abusos clásicos, y no son teóricos: los vemos en los registros de casi todas las webs que revisamos.

1. Fuerza bruta amplificada con `system.multicall`

Un ataque normal contra el formulario de acceso de WordPress prueba una contraseña por petición. Eso es ruidoso y cualquier plugin de seguridad lo corta a los pocos intentos.

XML-RPC tiene un método llamado system.multicall que permite empaquetar cientos de intentos dentro de una sola petición HTTP. Para tu servidor es una visita; para el atacante son 500 contraseñas probadas. Los contadores de intentos fallidos, si solo miran el formulario de acceso, ni se enteran.

2. Pingbacks usados para atacar a terceros

El método pingback.ping hace que tu servidor visite una URL que le indique quien llame. Multiplicado por miles de WordPress, eso se convierte en una botnet de reflexión: tu web participa sin saberlo en una saturación contra un tercero. Consecuencias para ti: consumo de CPU, facturas de tráfico y, en hostings compartidos, suspensiones por abuso.

Señal de que te está pasando: picos de carga sin visitas que los justifiquen, y muchas líneas POST /xmlrpc.php con código 200 desde direcciones distintas. En cómo leer los logs de tu web tienes el detalle de dónde mirar.

Cómo saber si lo estás usando de verdad

Antes de desactivar, comprueba estos cuatro casos. Son los únicos que nos hemos encontrado en webs de pyme:

Si usas…	¿Necesita XML-RPC?	Qué hacer
La app móvil oficial de WordPress	Ya no: usa la API REST en instalaciones modernas	Puedes desactivarlo; prueba la app después
Jetpack (estadísticas, copias, protección)	Sí en varias funciones	Si lo mantienes, no lo desactives del todo: filtra por IP
Publicación desde herramientas externas (Windows Live Writer, plugins antiguos de sindicación)	Sí	Migra a la REST o mantén XML-RPC restringido
Nada de lo anterior	No	Desactívalo sin miedo

La comprobación rápida: pide a tu web https://tudominio.com/xmlrpc.php en el navegador. Si responde «XML-RPC server accepts POST requests only», está activo. Si da 403 o 404, ya está cerrado.

Las tres formas de desactivarlo, de mejor a peor

Opción 1: bloquearlo en el servidor (la buena)

Es la más eficaz porque la petición ni siquiera llega a PHP: no consume memoria ni ejecuta WordPress. En Apache, dentro del .htaccess de la raíz:

<Files xmlrpc.php>
  Require all denied
</Files>

En Nginx, dentro del bloque del sitio (lo pone tu proveedor o el administrador del servidor):

location = /xmlrpc.php {
    deny all;
}

Si necesitas dejar entrar a Jetpack, en lugar de denegar todo se permite el rango de direcciones del servicio y se deniega el resto. Tu hosting sabe hacerlo; si te dicen que no pueden tocar la configuración, es una señal más a valorar cuando compares qué hosting te conviene.

Opción 2: filtro de WordPress

Una línea en un mu-plugin o en el functions.php del tema hijo:

add_filter('xmlrpc_enabled', '__return_false');

Desactiva los métodos que requieren autenticación, que es lo que frena la fuerza bruta. Ojo: el fichero se sigue ejecutando, así que el gasto de CPU por petición continúa y los pingbacks no se cierran del todo. Complétalo con:

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

Opción 3: un plugin que lo haga por ti

Funciona, pero añade un plugin más al inventario para algo que se resuelve con dos líneas. Si ya tienes un plugin de seguridad, probablemente lleve la opción incorporada: mírala antes de instalar otro. Sobre ese criterio hablamos en qué plugin de seguridad merece la pena.

Después de desactivarlo, comprueba

Pide otra vez /xmlrpc.php: debe devolver 403 (bloqueo de servidor) o un error de método (filtro de WordPress).
Entra al escritorio y publica una entrada de prueba: nada de esto afecta al uso normal.
Si usas Jetpack, abre su panel y confirma que sigue conectado.
Vuelve a los registros al día siguiente: las peticiones seguirán llegando —los escáneres no se enteran— pero ya no consumirán PHP.

Lo que desactivar xmlrpc.php NO arregla

Conviene decirlo para que nadie se quede tranquilo de más: cerrar XML-RPC elimina un vector de acceso, no limpia una web ya comprometida ni sustituye a lo básico. Si la contraseña de administrador es débil, seguirán entrando por el formulario normal; si tienes un plugin vulnerable sin actualizar, entrarán por ahí sin tocar el acceso.

Es una pieza de la configuración segura de la web, y encaja junto a las cabeceras de seguridad HTTP y la verificación en dos pasos. El orden que recomendamos: contraseñas y segundo factor primero, plugins al día después, y este tipo de cierres a continuación.

La documentación oficial del método está en el manual para desarrolladores de WordPress, por si tu programador quiere confirmar qué depende de qué antes de tocarlo.

Seguir leyendo en esta sección

Ver todo en Endurecer tu web → · Mapa completo del sitio