xmlrpc.php en WordPress: Qué es, riesgos de seguridad y cómo desactivarlo

Puntos clave

• Dejar abierto xmlrpc.php expone tu sitio a ataques de fuerza bruta y DDoS, mientras que desactivarlo manualmente mediante .htaccess puede romper tu sitio web.
• Los plugins de seguridad pueden bloquear las peticiones XML-RPC, pero añaden una hinchazón innecesaria de la base de datos y ralentizan la velocidad general de carga de la página.
• Protege tu sitio sin esfuerzo con el complemento Cloudways 1-click XML-RPC, y atrapa cargas útiles ocultas con el complemento Malware Protection por sólo 4 $/mes por aplicación.

Los registros del servidor muestran a veces picos repentinos en el uso de recursos, en los que miles de peticiones automatizadas llegan a un archivo específico llamado xmlrpc.php. Esta actividad agota rápidamente las CPU del servidor e indica un ataque activo de fuerza bruta, más que un aumento del tráfico legítimo.

El archivo wordpress xmlrpc se creó originalmente para ayudar a las aplicaciones externas a interactuar con un sitio. Ahora está en gran medida obsoleto y funciona principalmente como una puerta abierta para que los bots prueben las contraseñas.

Asegurar los puntos finales expuestos, como XML-RPC, es un primer paso fundamental en la seguridad integral de un sitio web. La forma más sencilla de detener estos ataques y preservar los recursos de tu servidor es cerrar el archivo por completo.

En este blog, examinaremos la finalidad original de este archivo obsoleto, expondremos los riesgos de seguridad específicos que introduce y proporcionaremos instrucciones paso a paso sobre cómo desactivarlo de forma segura.

¿Qué es xmlrpc.php en WordPress?

Antes de que la API REST se convirtiera en el estándar, xmlrpc.php era la principal forma que tenía WordPress de comunicarse con aplicaciones externas.

Si querías publicar un post desde una aplicación móvil o una herramienta de blogging de terceros, este archivo se encargaba de la conexión.

Permitía a los usuarios eludir el panel de administración principal sin dejar de interactuar con su sitio. También gestionaba los pingbacks y trackbacks. Cada vez que enlazabas a otro blog en tu contenido, el protocolo XML-RPC enviaba una notificación automática a ese sitio web.

La tecnología subyacente ha cambiado significativamente desde aquellas primeras versiones. La API REST de WordPress ha sustituido en gran medida a XML-RPC y gestiona la comunicación externa de forma mucho más segura.

Como resultado, este archivo heredado ha quedado obsoleto. Para casi todos los sitios web modernos, no sirve para nada y simplemente deja abierto un punto de acceso innecesario en tu servidor.

Los Riesgos de Seguridad: Por qué deberías desactivar xmlrpc.php

Como hemos dicho antes, dejar abierto este punto de acceso innecesario en tu servidor es exactamente la razón por la que el archivo es un gran lastre.

Los piratas informáticos aprovechan funciones específicas integradas en xmlrpc.php para saltarse los límites de seguridad estándar y comprometer los entornos WordPress.

Ataques de inicio de sesión por fuerza bruta

Las páginas de inicio de sesión estándar estrangulan los intentos de contraseña. Si un script intenta adivinar una contraseña de administrador en wp-login.php, las medidas básicas de seguridad bloquean la dirección IP tras unos cuantos intentos fallidos. XML-RPC elude por completo estas protecciones.

Los hackers utilizan un comando llamado system.multicall para agrupar cientos de intentos de adivinar contraseñas en una única petición HTTP.

Esta técnica les permite recorrer rápidamente listas masivas de credenciales sin provocar bloqueos de inicio de sesión. Estas solicitudes de fuerza bruta casi siempre se llevan a cabo mediante un ataque botnet automatizado.

Ataques DDoS y caída de servidores

La función pingback se diseñó originalmente para las notificaciones de los blogs, pero el protocolo carece de verificación. Un atacante puede falsificar la dirección IP de tu sitio web y enviar solicitudes de pingback a miles de otros sitios WordPress simultáneamente.

Cada uno de esos sitios externos responde inmediatamente haciendo ping a tu servidor. Esta repentina y masiva oleada de tráfico entrante agota la CPU y la memoria de tu servidor, provocando la caída del sitio.

Infecciones de malware y ocupaciones de sitios web

Un servidor colapsado es un problema temporal de rendimiento, pero un ataque de fuerza bruta con éxito es una brecha crítica. Si el exploit multicall consigue adivinar tus credenciales de administrador, el atacante obtiene el control total de tu entorno de alojamiento.

Una vez que adivinan tu contraseña mediante XML-RPC, lo primero que hacen es instalar una puerta trasera oculta de WordPress. Utilizan este acceso persistente para soltar cargas maliciosas, modificar archivos del núcleo o redirigir tu tráfico orgánico a dominios maliciosos.

Automatiza tu defensa contra el malware

Detén en seco las puertas traseras ocultas. El complemento Cloudways Malware Protection aísla y elimina automáticamente las cargas maliciosas en el nivel del sistema operativo antes de que puedan ejecutarse.

Activar Protección

Cómo comprobar si xmlrpc.php se está ejecutando en tu sitio web

Tienes tres formas sencillas de verificar si este punto final está activo en tu instalación de WordPress.

1. La prueba del navegador

El método más rápido no requiere herramientas externas. Abre tu navegador, escribe tu dominio y añade /xmlrpc.php al final de la URL.

Si la página carga una pantalla en blanco con una sola línea que dice «XML-RPC server accepts POST requests only,«, el archivo está expuesto y activo. Si ves un error 403 Prohibido o 404 No encontrado, tu servidor ya está bloqueando el acceso.

2. Herramientas de validación en línea

También puedes realizar una comprobación de diagnóstico utilizando un validador XML-RPC online gratuito. Estas aplicaciones web simulan el tipo exacto de peticiones externas que haría un bot.

Si tu sitio es seguro y el archivo está bloqueado, la herramienta no podrá conectarse.

Si el punto final se deja completamente abierto, el validador pasará con éxito la comprobación y confirmará la vulnerabilidad.

3. El método de la línea de comandos

Si prefieres trabajar en el terminal, puedes enviar una solicitud POST directa utilizando un comando cURL. Pega la siguiente línea en tu terminal, sustituyendo la URL ficticia por tu nombre de dominio real:

curl -d "system.listMethods" https://yourdomain.com/xmlrpc.php

Si el archivo está activado, tu servidor te devolverá una respuesta XML sin estructurar con una lista de los métodos disponibles.

Cómo desactivar xmlrpc.php (Los métodos manuales)

Si administras tu propio servidor o utilizas un host compartido básico, tienes dos formas tradicionales de desactivar este punto final manualmente.

Método 1: Desactivación mediante un plugin

La solución manual más sencilla es instalar un plugin de seguridad dedicado como Desactivar XML-RPC. Una vez instalado y activado, el plugin bloquea automáticamente las peticiones entrantes al archivo.

Ya está.

Pero… el principal inconveniente de este enfoque es la hinchazón de la base de datos. Añadir plugins de propósito único añade una sobrecarga innecesaria a tu instalación de WordPress.

Cada plugin adicional obliga a tu servidor a procesar más código en cada carga de página, lo que a la larga ralentiza el rendimiento de tu sitio web.

Método 2: Desactivar mediante .htaccess o reglas del servidor

Si quieres evitar plugins hinchados y buscas una alternativa ligera a Wordfence, es preferible el bloqueo a nivel de servidor. Puedes bloquear el acceso por completo modificando los archivos de configuración de tu servidor central.

Para servidores Apache, accede a tu sitio a través de SFTP o del gestor de archivos de tu host. Localiza el archivo .htaccess en tu carpeta raíz (normalmente public_html) y pega el siguiente fragmento:

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

Si estás ejecutando un servidor NGINX, tendrás que añadir este bloque de código a tu bloque de servidor en su lugar:

location = /xmlrpc.php {
    deny all;
}

El riesgo: Editar manualmente los archivos de configuración del servidor central es muy arriesgado. Omitir un solo corchete, utilizar una sintaxis incorrecta o pegar el código en la sección equivocada provocará inmediatamente un Error Interno del Servidor 500 y desconectará todo tu sitio web.

Crea siempre una copia de seguridad de tu archivo .htaccess o de bloqueo del servidor antes de realizar cualquier cambio. Si eres usuario de Cloudways, puedes crear rápidamente una copia de seguridad completa bajo demanda con un solo clic desde el panel de Gestión de Aplicaciones.

Defensa automatizada contra exploits XML-RPC: El complemento Cloudways Malware Protection

Si alojas tu sitio WordPress en Cloudways, no necesitas arriesgarte a romper tu sitio con ediciones manuales del servidor. Tienes acceso a herramientas a nivel de plataforma que bloquean el punto de entrada XML-RPC, filtran el tráfico malicioso y detienen automáticamente las cargas útiles de malware.

Atrapar la carga útil con protección antimalware

Si un atacante consigue saltarse tus límites de acceso mediante un exploit de fuerza bruta XML-RPC, su siguiente paso inmediato será introducir una puerta trasera en tu servidor. Encontrar manualmente estos scripts ocultos requiere profundos conocimientos técnicos y una valiosa pérdida de tiempo.

El complemento Cloudways Malware Protection actúa como un sistema de seguridad automatizado contra estos ataques. Desarrollado por Imunify360, funciona a nivel de sistema operativo para proteger todo tu entorno de servidor.

• Bloqueo activo de amenazas: Utiliza la autoprotección de aplicaciones en tiempo de ejecución (RASP) para aislar instantáneamente las puertas traseras ocultas lanzadas por los atacantes. Detiene la ejecución del código malicioso antes de que el hacker pueda tomar el control.
• Limpieza automatizada: Analiza todo tu servidor para localizar los scripts ocultos resultantes de una violación y limpia el código infectado sin dañar tus archivos principales legítimos.

Activarlo sólo requiere unos pocos clics, y el escaneo inicial se ejecuta completamente en segundo plano.

Paso 1: Navega a Seguridad de Aplicaciones

Accede a la plataforma Cloudways y selecciona tu aplicación de destino. Haz clic en Seguridad de Aplicaciones en el menú de gestión de la izquierda.

Paso 2: Activa el Complemento

Selecciona la pestaña Protección contra Malware y pulsa el botón Activar Protección. Esto activa la supervisión en tiempo real e inicia un exhaustivo escaneo en segundo plano de tus directorios y base de datos.

Paso 3: Supervisar los resultados

Puedes hacer un seguimiento de la limpieza automatizada a través de tres sencillas pestañas:

• Malicioso: Muestra las rutas exactas de los archivos de las amenazas aisladas y confirma si se limpiaron, pusieron en cuarentena o eliminaron.
• Historial de escaneos: Proporciona un registro de escaneos anteriores y te permite activar comprobaciones manuales.
• Defensa proactiva: Registra los eventos de tiempo de ejecución en los que se bloqueó la ejecución de scripts PHP maliciosos.

El conmutador XML-RPC de 1 clic

Aunque Malware Protection se encarga de las cargas útiles eliminadas, deberías cerrar completamente el punto de entrada XML-RPC. Cloudways proporciona un conmutador integrado que aplica las reglas a nivel de servidor de forma instantánea, ahorrándote las arriesgadas ediciones de .htaccess.

• Ve a Configuración de la aplicación en tu panel de control.
• En la pestaña Ajustes de WordPress, busca el conmutador XML-RPC.
• Cámbialo a Desactivado.

Detener el tráfico de robots en el borde

Desactivar el archivo impide que los hackers inicien sesión, pero los scripts automatizados seguirán haciendo ping repetidamente al punto final cerrado. Miles de estas peticiones fallidas seguirán consumiendo la CPU de tu servidor.

El complemento Cloudways Cloudflare Enterprise resuelve este problema. Su cortafuegos de aplicaciones web de nivel empresarial actúa como un filtro de borde. Identifica el tráfico malicioso y bloquea las peticiones XML-RPC de fuerza bruta antes de que lleguen a tu servidor.

Obtén más información sobre cómo el filtrado de borde protege tus recursos en nuestra comparativa WAF vs. cortafuegos.

¿Cuándo necesitas realmente mantener activado xmlrpc.php?

Para el 99% de los sitios web WordPress modernos, la respuesta es nunca.

Desde la introducción de la API REST de WordPress en la versión 4.7, casi todas las herramientas de publicación remota, aplicaciones móviles y plugins importantes han migrado a la API basada en JSON, más nueva, rápida y segura.

La única vez que deberías dejar este archivo activo es si te enfrentas a un caso extremo muy específico:

• Utilizas una aplicación de publicación remota heredada y personalizada que no se ha actualizado en años.
• Estás ejecutando un plugin específico y obsoleto que requiere explícitamente el protocolo XML-RPC para funcionar y no puede ser sustituido.

Una buena regla general: si no estás completamente seguro de si necesitas xmlrpc.php, no lo necesitas. Puedes desactivarlo con total seguridad.

¡Terminando!

El archivo xmlrpc.php ha existido desde los primeros tiempos de WordPress, pero ya no es relevante para la mayoría de los sitios. Hoy en día, principalmente crea riesgos de seguridad al ofrecer a los atacantes una forma fácil de lanzar ataques de fuerza bruta y DDoS.

Dejarlo abierto es un riesgo que no debes correr.

Tanto si lo bloqueas manualmente a través de tu archivo .htaccess como si utilizas el conmutador de 1 clic en tu panel de control de Cloudways, desactivar este endpoint debería ser una parte estándar de tu lista de comprobación de seguridad.

Para mayor tranquilidad, combina esta medida preventiva con el complemento Cloudways Malware Protection para asegurarte de que cualquier amenaza automatizada se detecta y limpia antes de que pueda ejecutarse.