¿Qué es xmlrpc.php y cómo lo desactivo en WordPress?

Por qué importa

XML-RPC es una antigua interfaz de control remoto de WordPress. Antes de que existiera la API REST, era la forma en que los editores de escritorio y las apps móviles publicaban entradas. Sigue incluido en todos los sitios WordPress, en /xmlrpc.php, y sigue aceptando un nombre de usuario y una contraseña con cada petición.

Eso lo convierte en una segunda puerta de acceso. Ocultar wp-login.php no la toca. El código de límite de accesos que solo vigila el formulario de acceso no la ve. Y con system.multicall, una sola petición HTTP puede llevar cientos de intentos de contraseña. Un límite que cuenta peticiones ve un intento donde hubo quinientos.

No es teoría. Creamos esta capa después de que una tienda siguiera recibiendo intentos de contraseña a través de XML-RPC cuando su página de acceso ya estaba oculta.

¿Usas XML-RPC? Probablemente no, si no te ocurre nada de esto:

• Conectas el sitio a Jetpack.
• Publicas o moderas desde la app móvil oficial de WordPress.
• Usas una herramienta de blogging de escritorio antigua, o un servicio que te pide tu nombre de usuario y contraseña de WordPress (en lugar de una contraseña de aplicación) para publicar en tu nombre.
• Dependes de los pingbacks de otros blogs.

Si no estás seguro, cierra solo el acceso y mantén los pingbacks. Así eliminas el riesgo de que adivinen contraseñas y dejas en su sitio las partes inofensivas. Siempre puedes endurecerlo más adelante.

Errores habituales

• Ocultar el acceso y quedarse ahí. Los intentos de adivinar contraseñas simplemente se trasladan a xmlrpc.php.
• Bloquear el archivo entero sin comprobar. Jetpack y la app móvil oficial de WordPress se conectan por XML-RPC. Si los usas, cierra solo los métodos de acceso o haz pruebas con cuidado.
• Fiarse de un interruptor sin probarlo. Algunos métodos dejan partes de XML-RPC respondiendo. Comprueba siempre el resultado con una petición real (consulta el paso 4 o comprueba qué expone tu sitio).
• Olvidar la capa de caché. Si una regla de la CDN ya bloquea xmlrpc.php, un ajuste a nivel de WordPress no mostrará ningún efecto. No pasa nada; solo tienes que saber qué capa está haciendo el trabajo.

Sin plugin

Opción 1: el filtro xmlrpc_enabled. Añade esto a un pequeño plugin de uso obligatorio (wp-content/mu-plugins/no-xmlrpc-login.php) o al functions.php de tu tema hijo:

<?php
add_filter( 'xmlrpc_enabled', '__return_false' );

Esto desactiva los métodos de XML-RPC que requieren iniciar sesión. Los pingbacks siguen funcionando porque no lo necesitan. Por sí solo no elimina system.multicall, y el archivo sigue respondiendo a las peticiones. Para quitar también el método multicall:

<?php
add_filter( 'xmlrpc_methods', function ( $methods ) {
    unset( $methods['system.multicall'] );
    return $methods;
} );

Opción 2: bloquear el archivo en el servidor. En Apache, en .htaccess:

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

En Nginx: location = /xmlrpc.php { deny all; }. Es la opción más estricta y no le cuesta nada al servidor, pero también acaba con los pingbacks, Jetpack y la app móvil, y vive fuera de WordPress, así que es fácil olvidarla cuando cambias de hosting.

Si algo sale mal

• Jetpack muestra un error de conexión. Jetpack necesita XML-RPC. Cambia de «Desactivar por completo» a «Desactivar el acceso, mantener los pingbacks», o quita tu regla del servidor.
• La app móvil de WordPress no puede acceder. La misma causa. O usas el navegador en el móvil, o permites el acceso por XML-RPC y confías en los límites de acceso más la autenticación de dos factores.
• Una herramienta de publicación ha dejado de publicar. Comprueba si usa XML-RPC. La mayoría de las herramientas modernas se han pasado a la API REST con contraseñas de aplicación.

Con Hushfort

El Cierre de la puerta trasera forma parte de Hushfort Pro. El Análisis de superficie, que muestra si XML-RPC está abierto, está en Hushfort Security, el plugin de seguridad gratuito para WordPress.

El Cierre de la puerta trasera forma parte de la capa de Blindaje de superficie de Hushfort. Te ofrece cuatro opciones:

• Desactivar el acceso, mantener los pingbacks (recomendado): adivinar contraseñas por XML-RPC se vuelve imposible, mientras los pingbacks y trackbacks siguen funcionando. Encaja bien en tiendas online.
• Desactivar por completo: la opción más estricta. Jetpack y la app móvil oficial no pueden conectarse.
• Desactivar solo system.multicall: cierra los intentos masivos y deja el resto como está.
• No cambiar: el comportamiento predeterminado de WordPress.

Después, el Análisis de superficie comprueba el resultado con peticiones reales, para que veas lo que ve alguien de fuera. La Protección de carga, además, cobra más por las peticiones a xmlrpc.php que por una visita normal a una página, lo que frena el ruido que quede.