xmlrpc.php brute force amplificado: cómo frenarlo

En pocas palabras: xmlrpc.php multiplica el brute force porque el método system.multicall permite empaquetar hasta 1999 intentos de login en una sola petición HTTP, acelerando hasta 100 veces la prueba de credenciales frente a wp-login.php. Según telemetría de Wordfence, en mayo de 2026 se registraron 150 millones de ataques contra este endpoint.

Los atacantes siguen usando xmlrpc.php para lanzar ataques de fuerza bruta amplificados contra WordPress, y la clave del xmlrpc.php brute force amplificado es system.multicall, un método que permite probar miles de contraseñas dentro de una sola petición HTTP.

Antes de seguir, la definición que importa: xmlrpc.php es un archivo incluido en WordPress desde la versión 1.5 que expone la interfaz XML-RPC, un protocolo remoto para administrar el sitio desde aplicaciones externas. El ataque de brute force amplificado explota el método system.multicall, que admite hasta 1999 llamadas en una única solicitud HTTP y multiplica por hasta 100 la velocidad de prueba de credenciales frente a un ataque tradicional contra wp-login.php.

¿Qué es xmlrpc.php y por qué WordPress lo incluye?

Ponele que estás de viaje y aprobás comentarios desde la app de WordPress en el celular. Esa comunicación entre la app y tu sitio pasa por xmlrpc.php. Lo mismo cuando Jetpack sincroniza estadísticas o cuando un editor externo publica por vos.

XML-RPC es un protocolo heredado que usa XML sobre HTTP para invocar funciones remotas. WordPress lo incorporó en la versión 1.5 (2005) para integrarse con clientes de escritorio, y desde la versión 3.5 (diciembre de 2012) viene activado por defecto en toda instalación nueva. Con este endpoint se puede publicar, editar entradas, moderar comentarios y consultar información del sitio sin abrir el panel de administración.

Ojo con una distinción que suele confundirse: el archivo es la puerta, los métodos son lo que hay detrás. wp.getUsersBlogs, wp.getPosts, system.multicall y compañía son operaciones concretas que cualquiera puede invocar si sabe hablarle al endpoint. El problema nunca fue el archivo en sí, sino que expone operaciones sensibles a quien llegue con el XML correcto.

Es una puerta de servicio. Y como toda puerta de servicio descuidada, termina siendo la entrada favorita de los ladrones. Te puede servir nuestra cobertura de qué plugin de seguridad conviene instalar.

¿Cómo funciona el xmlrpc.php brute force amplificado?

El mecanismo es simple y brutal: system.multicall es un método estándar de XML-RPC que acepta un array de llamadas y las ejecuta todas en secuencia dentro de la misma petición HTTP.

Comparemos. Contra wp-login.php, cada intento de login exige un request completo con sus headers, cookies y redirecciones: una prueba por petición. Contra xmlrpc.php, el atacante arma un único POST con hasta 1999 estructuras de wp.getUsersBlogs, cada una con un usuario y una contraseña distinta. Un solo request (sí, en serio, uno solo) y el servidor prueba las 1999 combinaciones seguidas. Sucuri demostró este vector en octubre de 2015 y estimó un potencial de amplificación de hasta 100 veces según la configuración del servidor.

¿Y qué queda en tus logs? Un único POST a /xmlrpc.php. Nada de mil intentos fallidos que dispararan alertas.

Esa eficiencia explica números como los 150 millones de intentos que la telemetría de Wordfence registró en mayo de 2026. Cuando probarlas sale casi gratis, los diccionarios de contraseñas se recorren enteros, noche tras noche, en miles de sitios a la vez.

Y el escenario típico es siempre el mismo: subís un plugin, activás Jetpack, la app móvil empieza a publicar, todo funciona bárbaro, y de repente un martes a las tres de la mañana el CPU del servidor se va al techo porque alguien descubrió que tu xmlrpc.php responde feliz a system.multicall y lleva horas recorriendo diccionarios completos de contraseñas en tandas de dos mil.

¿Por qué xmlrpc.php no tiene las protecciones de wp-login.php?

Porque es un endpoint programático pensado para máquinas, no un formulario para humanos. Y esa diferencia de diseño lo deja afuera de casi todas las defensas clásicas.

Sobre wp-login.php los plugins de seguridad montan CAPTCHA, bloqueo de cuenta tras N intentos fallidos y límites de frecuencia, porque el formulario dispara los hooks de login que esas herramientas escuchan. xmlrpc.php responde XML directo, sin interfaz visual, sin cookies de sesión a la vista, y durante años muchos sistemas de protección ni lo miraban. Es un endpoint «silencioso»: no muestra formularios, no pide captchas, no molesta. Justo lo que un atacante busca. Tema relacionado: limpiar el sitio tras una intrusión.

Hay un detalle técnico que agrava todo: el endpoint suele responder con código HTTP 200 incluso cuando las credenciales fallan, porque el error viaja dentro del cuerpo XML como un fault. Cualquier defensa que cuente errores por código de respuesta HTTP se lleva la sorpresa de que «todo salió bien».

Enumeración de usuarios: cómo los atacantes identifican blancos válidos

Antes del brute force viene la enumeración, y wp.getUsersBlogs es la herramienta de reconocimiento. El atacante envía un nombre de usuario con una contraseña inventada y analiza la respuesta: el mensaje o el código de error difiere según la cuenta exista o no, y esa diferencia confirma usuarios válidos. Invicti documenta esta técnica como fase previa estándar del ataque.

Una respuesta de fallo típica se ve así:

<methodResponse>
 <fault>
 <value>
 <struct>
 <member>
 <name>faultCode</name>
 <value><int>403</int></value>
 </member>
 <member>
 <name>faultString</name>
 <value><string>Incorrect username or password.</string></value>
 </member>
 </struct>
 </value>
 </fault>
</methodResponse>

Con la lista corta de usuarios reales (admin, editor, el nombre de la persona que publica), el multicall rinde muchísimo más: probás contraseñas solo contra cuentas que existen en vez de quemar ciclos con usuarios fantasma. Por eso conviene evitar el usuario «admin» y no publicar con un nick idéntico al nombre de usuario.

¿Cómo detectar ataques de xmlrpc.php en los logs?

Buscá concentraciones de POST a /xmlrpc.php desde pocas IPs o picos sostenidos de tráfico hacia ese archivo. Estos son los patrones que delatan el ataque:

• Múltiples POST seguidos: decenas o cientos de peticiones a /xmlrpc.php desde la misma IP en cuestión de minutos.
• Cuerpo con system.multicall: si podés inspeccionar el payload, la presencia de ese método con arrays gigantes es la firma directa del ataque amplificado.
• Picos fuera de horario: tráfico nocturno constante hacia xmlrpc.php en un sitio que no usa apps móviles no es casualidad.
• Respuestas 200 con faults internos: el código HTTP no delata nada; el contenido de la respuesta, sí.

Como herramientas, tenés los logs de acceso del servidor (Apache o NGINX), el Live Traffic de Wordfence filtrando por xmlrpc.php, y Google Search Console para cruzar anomalías de rastreo. Wordfence diferencia tráfico legítimo de ataques comparando firmas de exploits conocidas con la reputación de la IP, así que sus bloqueos suelen venir etiquetados con el motivo.

Eso sí: descartá falsos positivos antes de entrar en pánico. Jetpack hace pings periódicos vía XML-RPC y la app móvil también genera tráfico espaciado y regular. Si las peticiones vienen desde infraestructura de Automattic y tienen cadencia estable, respirá.

Métodos para bloquear o limitar xmlrpc.php en WordPress

Hay cinco caminos, y todos empiezan con la misma pregunta: ¿usás algo que dependa de XML-RPC? Si la respuesta es no, bloqueá y listo. Estas son las opciones concretas: Ya lo cubrimos antes en parchear las vulnerabilidades conocidas de WordPress.

1) .htaccess en Apache o LiteSpeed. La más directa si tu hosting corre Apache:

<Files xmlrpc.php>
 Order Allow,Deny
 Deny from all
</Files>

2) Bloque de ubicación en NGINX. Para VPS y servidores dedicados:

location = /xmlrpc.php {
 deny all;
 access_log off;
}

3) Filtro xmlrpc_enabled. Agregá esto en el functions.php de tu tema hijo o en un mu-plugin:

add_filter('xmlrpc_enabled', '__return_false');

(Acordate de esto: varios tutoriales dicen de pegarlo en wp-config.php. Spoiler: ahí no funciona, porque el sistema de hooks de WordPress todavía no cargó cuando se lee ese archivo.)

4) Plugin dedicado. Disable XML-RPC hace el trabajo con un clic, ideal si no querés tocar código.

5) Firewall de Wordfence. Bloqueo a nivel de reglas con registro de intentos, útil si ya usás el plugin. Lo explicamos a fondo en detener estos ataques en el perímetro.

Si tu plan de hosting compartido (la mayoría, incluidos los de donweb.com, corren Apache o LiteSpeed) te da acceso a archivos o cPanel, la opción 1 te toma menos de cinco minutos.

¿Cómo configurar límites de velocidad si necesitás xmlrpc.php activo?

Si tenés integraciones legítimas, la jugada es limitar frecuencia y monitorear, no bloquear todo. En Wordfence, andá a Wordfence > Firewall > Brute Force Protection y ajustá el máximo de intentos fallidos permitidos en valores iguales o más bajos que los que uses para wp-login.php; después revisá periódicamente el Live Traffic filtrando por xmlrpc.php. La guía de Seguridad en WordPress sobre protección con Wordfence detalla el paso a paso.

A nivel de servidor, ModSecurity permite escribir reglas que limiten la frecuencia de POST contra el endpoint, y Cloudflare ofrece reglas WAF para desafiar o rechazar peticiones a /xmlrpc.php provenientes de IPs desconocidas. Si tu integración remota viene de IPs fijas, una allowlist estricta cierra el resto del mundo de golpe.

¿Cuándo NO conviene desactivar xmlrpc.php?

Hay casos donde apagarlo rompe cosas que usás todos los días. Jetpack depende de XML-RPC para sincronizar y administrar el sitio, así que al desactivarlo perdés esa conexión (y no es poco decir que Jetpack está en millones de instalaciones). La app móvil oficial de WordPress también publica a través de este endpoint, igual que varias herramientas de gestión remota heredadas.

Si necesitás mantenerlo vivo, hacelo bien: contraseñas únicas y largas en cuentas con permisos de publicación, segundo factor activo para esos usuarios, restricción por IP cuando la integración lo permita y monitoreo constante de los logs. La alternativa moderna es migrar esas integraciones a la REST API con application passwords, disponible desde WordPress 5.6: credenciales revocables por aplicación y mucho mejor compatibilidad con los sistemas de detección actuales.

Qué está confirmado y qué no

• Confirmado: la técnica de amplificación existe y está documentada; Sucuri publicó la primera explotación en julio de 2014 y la demostración completa en octubre de 2015.
• Confirmado: system.multicall admite cientos de llamadas por petición, con un límite práctico cercano a las 1999 según la implementación del servidor.
• Confirmado: Wordfence detecta y bloquea estos ataques de forma masiva; su telemetría de mayo de 2026 registró 150 millones de intentos.
• No confirmado: no existe un CVE asociado, porque es abuso de una funcionalidad legítima y no un bug de código; no esperes un parche que lo «arregle».
• A tomar con pinzas: las cifras exactas de campañas vigentes varían según la red y el período; la telemetría sirve como orden de magnitud, no como censo.

Errores comunes al blindarse contra el brute force por xmlrpc

• Borrar el archivo del servidor. Parece lógico, pero cada actualización de WordPress lo restaura. Bloqueá el acceso con reglas; el archivo puede existir mientras nadie lo alcance.
• Blindar solo wp-login.php. Si tu plugin de seguridad limita intentos en el formulario pero ignora XML-RPC, el atacante entra por la otra puerta sin despertar ninguna alerta.
• Pegar el filtro en wp-config.php. add_filter necesita que WordPress haya cargado su sistema de hooks; en wp-config eso todavía no pasó. Va en functions.php o en un mu-plugin.
• Desactivar sin auditar dependencias. Jetpack deja de sincronizar y la app móvil no publica, y te enterás cuando el equipo de contenidos te llama molesto.
• Renombrar el archivo y relajarte. Los escáneres buscan xmlrpc.php en rutas estándar; esconderlo es «seguridad» de papel.

Preguntas Frecuentes

¿Qué es system.multicall en xmlrpc.php?

Es un método del protocolo XML-RPC que agrupa varias llamadas dentro de una sola petición HTTP. En WordPress, los atacantes lo usan para incluir hasta 1999 intentos de inicio de sesión en un único POST, multiplicando la velocidad del brute force frente a un ataque tradicional.

¿Por qué xmlrpc.php es peligroso en WordPress?

Porque expone autenticación y gestión remota sin las protecciones del formulario de login: no aplica CAPTCHA, ni bloqueo de cuenta, ni límite de intentos nativo. Combinado con system.multicall, permite probar miles de contraseñas generando un tráfico mínimo y difícil de distinguir en los logs.

¿Cómo sé si mi sitio está sufriendo un ataque por xmlrpc?

Revisá los logs de acceso: muchas peticiones POST a /xmlrpc.php desde la misma IP o picos sostenidos son la señal típica. Con Wordfence, filtrá el Live Traffic por xmlrpc.php y revisá los bloqueos registrados; si usás Jetpack, descartá primero sus pings legítimos para no confundirlos con el ataque.

¿Es seguro borrar xmlrpc.php directamente del servidor?

No es la mejor opción: cualquier actualización de WordPress vuelve a crear el archivo. Lo correcto es denegar el acceso mediante .htaccess, NGINX o el filtro xmlrpc_enabled, de modo que el archivo exista pero ningún request pueda alcanzarlo.

¿Deja de funcionar la app móvil o Jetpack si desactivo XML-RPC?

Sí, ambas dependen de xmlrpc.php: la app móvil no podría publicar y Jetpack perdería su canal de sincronización. Si las usás, aplicá límites de frecuencia y segundo factor en lugar de desactivar, o migrá esas tareas a la REST API con application passwords.

Conclusión

Lo que cambió no es la técnica, es la escala. Sucuri describió el vector en 2015 y la telemetría de Wordfence de mayo de 2026 muestra 150 millones de intentos: once años después, el ataque sigue siendo rentable porque un solo request vale por casi dos mil pruebas.

Para vos esto significa una tarea concreta hoy: verificá si algún flujo de tu sitio depende de XML-RPC. Si no depende nadie, bloqueá el endpoint con .htaccess o el filtro xmlrpc_enabled y listo, son quince minutos. Si depende alguien, configurá límites de intentos en Wordfence, activá segundo factor y poné el endpoint bajo vigilancia. La puerta de servicio puede quedar abierta, pero con cámaras y un portero.

Fuentes

• Sucuri – Ataques de amplificación de fuerza bruta contra XML-RPC de WordPress (investigación original)
• Sucuri – Los ataques de fuerza bruta: nueva explotación de XML-RPC en WordPress
• Invicti – Fuerza bruta de autenticación por XML-RPC en WordPress
• Seguridad en WordPress – Cómo bloquear xmlrpc.php paso a paso
• Neubox – xmlrpc.php: qué es y cómo deshabilitarlo en WordPress