Cómo bloquear xmlrpc.php en WordPress es más simple de lo que parece: con tres líneas en .htaccess o la opción de Wordfence en Brute Force Protection alcanza para cerrar el vector. Lo que no es tan simple es que en mayo de 2026, según Ondú Cloud, los ataques automatizados contra este endpoint superaron los 150 millones de intentos registrados, y la mayoría de los sitios todavía tienen el archivo habilitado por defecto.
En 30 segundos
- xmlrpc.php es el endpoint legacy de WordPress que permite fuerza bruta amplificada: cientos de contraseñas en un solo request HTTP, sin rate limiting nativo.
- En mayo de 2026 se registraron más de 150 millones de intentos automatizados contra este archivo en sitios WordPress activos.
- La gran mayoría de sitios no necesita xmlrpc.php: la REST API de WordPress reemplazó su funcionalidad desde la versión 4.7 (2016).
- Hay 5 métodos para bloquearlo: .htaccess, NGINX, wp-config.php, plugin dedicado, y Wordfence Firewall.
- Bloquearlo a nivel de servidor (no solo con un filtro PHP) reduce el consumo de CPU del hosting y elimina el vector por completo.
¿Qué es xmlrpc.php en WordPress y para qué sirve?
xmlrpc.php es un archivo incluido en todas las instalaciones de WordPress que implementa el protocolo XML-RPC: un sistema de llamadas a procedimientos remotos via HTTP usando XML como formato de intercambio. Es la puerta oficial que WordPress dejó abierta para que herramientas externas pudieran publicar entradas, gestionar comentarios y administrar el sitio sin pasar por el panel de administración.
En su momento tuvo sentido. Aplicaciones como Windows Live Writer, MarsEdit o BlogDesk usaban xmlrpc.php para publicar remotamente. La app móvil oficial de WordPress lo usaba para conectarse al sitio. Servicios de agregación de contenido lo necesitaban para leer y escribir posts desde fuentes externas. Todo esto, antes de que existiera algo mejor.
El problema es que ese «mejor» llegó en 2016. WordPress 4.7 introdujo la REST API como estándar, y a partir de ahí cualquier cosa que antes hacía xmlrpc.php la hace la REST API, con autenticación moderna, manejo de permisos granular y rate limiting que xmlrpc.php nunca tuvo. xmlrpc.php quedó como pieza de museo, activa por defecto en todas las instalaciones, esperando que alguien la aproveche. Y alguien la aprovecha.
Bastante.
Riesgos de seguridad de xmlrpc.php en 2026: ataques actuales
Mayo de 2026 dejó números que no tienen vuelta atrás: Ondú Cloud reportó más de 150 millones de intentos automatizados contra endpoints xmlrpc.php en su infraestructura. Otros proveedores de hosting en la región reportaron picos de CPU inexplicables en clientes WordPress que, al revisar los logs, tenían en común un bombardeo constante a ese archivo (que no es poco, considerando que muchos de esos sitios son pequeños negocios con hosting compartido).
Lo que hace a estos ataques especialmente complicados: muchas veces no buscan comprometer el sitio directamente. El objetivo es consumir recursos del servidor hasta generar alertas de uso excesivo o tirar el hosting por sobrecarga. El sitio queda como víctima colateral del ataque a la infraestructura.
¿Y cómo lo detectás si no estás mirando los logs? La respuesta honesta es que muchas veces no lo detectás. Eso es lo que hace a xmlrpc.php tan atractivo para los bots: es silencioso, está habilitado por defecto, y en hosting compartido puede generar problemas que afectan a otros sitios en el mismo servidor sin que el dueño del sitio objetivo sepa nada hasta que el proveedor de hosting le manda un aviso.
¿Por qué xmlrpc.php es el objetivo preferido de los atacantes?
Comparado con wp-login.php (el otro vector clásico de fuerza bruta), xmlrpc.php tiene una ventaja estructural para el atacante: el método system.multicall.
Ponele que querés probar 500 contraseñas para un usuario de WordPress. Si atacás wp-login.php, mandás 500 requests HTTP separados. La mayoría de los firewalls o plugins de seguridad bloquean la IP después de 5 o 10 intentos fallidos. 500 intentos quedan en 0 antes de terminar. Tema relacionado: diferentes plugins de seguridad.
Con xmlrpc.php, mandás un solo request que internamente contiene 500 llamadas encadenadas usando system.multicall. El servidor procesa las 500 pruebas y responde con los resultados en una sola respuesta HTTP. Desde el punto de vista del firewall, fue un único request. No hay rate limiting que cubra esto porque los 500 intentos suceden dentro del servidor, no en la capa HTTP. Wordfence documentó este vector de amplificación en 2015 y en 2026 sigue siendo igual de efectivo porque millones de sitios nunca cerraron el archivo.
El otro factor que lo hace atractivo: xmlrpc.php no tiene lockout nativo. WordPress bloquea cuentas después de intentos fallidos en el login estándar desde versiones recientes, pero esa protección no cubre xmlrpc.php a menos que uses un plugin específico o lo bloquees directamente. Los bots lo saben.
¿Necesitás xmlrpc.php? Casos de uso legítimos
La respuesta corta para la gran mayoría de sitios: no (spoiler: si tenés que preguntarte si lo necesitás, probablemente no lo necesitás).
Los casos donde xmlrpc.php se usaba y hoy tienen alternativa:
- App móvil oficial de WordPress: usa la REST API desde WordPress 4.7 (diciembre de 2016). Si tenés la app actualizada en 2026, no necesita xmlrpc.php para nada.
- Jetpack: las versiones recientes de Jetpack migraron sus funciones principales a la REST API. Si tenés Jetpack activo, verificá la documentación de tu versión antes de hacer un bloqueo total; algunas funciones específicas de sincronización pueden tener comportamientos distintos.
- Clientes de blog de escritorio: Windows Live Writer (descontinuado desde 2017), MarsEdit (solo Mac), BlogDesk. Si los usás, necesitás xmlrpc.php. Si no sabés qué son, no los usás.
- Integraciones de terceros legacy: herramientas de automatización o publicación desarrolladas antes de 2016. Si tus integraciones son actuales, ya usan la REST API.
Si no usás nada de esa lista, podés bloquear xmlrpc.php sin que nada se rompa. Antes de hacerlo, lo ideal es revisar los logs de acceso de tu hosting de los últimos 7 días y filtrar por solicitudes a xmlrpc.php con código 200 (respuesta exitosa). Si solo ves bots y escaneos automáticos, bloquealo sin dudar.
5 métodos para bloquear xmlrpc.php en WordPress
Hay varias formas de bloquear este archivo. La mejor depende de tu configuración de servidor, tu nivel técnico y si querés bloqueo total o control más granular:
| Método | Dificultad | Nivel de bloqueo | Persistencia | Compatible con actualizaciones WP |
|---|---|---|---|---|
| .htaccess (Apache) | Baja | Total (403) | Permanente | Sí |
| Configuración NGINX | Media | Total (403) | Permanente | Sí |
| wp-config.php (filtro PHP) | Baja | Parcial (responde con error PHP) | Permanente | Sí |
| Plugin Disable XML-RPC | Mínima | Parcial o total (configurable) | Mientras el plugin esté activo | Sí |
| Wordfence Firewall | Baja | Configurable | Permanente (con Wordfence activo) | Sí |
Método 1: bloquear xmlrpc.php con .htaccess
Funciona en servidores Apache, que es la mayoría de los planes de hosting compartido (incluyendo donweb.com y otros proveedores locales). Abrís el archivo .htaccess en la raíz de tu WordPress y agregás:
# Bloquear acceso a xmlrpc.php
<Files xmlrpc.php>
order deny,allow
deny from all
</Files>El servidor devuelve un 403 Forbidden a cualquier request antes de que PHP procese nada. Simple, efectivo, sin overhead de WordPress. El riesgo es uno: si tenés alguna integración legítima que use XML-RPC, se rompe sin aviso.
Método 2: bloquear xmlrpc.php en NGINX
Para servidores NGINX (VPS, cloud, algunos planes de hosting gestionado). Agregás esto en el bloque server {} de tu configuración:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Las líneas access_log off y log_not_found off evitan que el log de acceso se llene con los intentos bloqueados, que pueden ser miles por día. Si querés monitorear cuántos intentos bloqueás, sacalas. En otras soluciones de protección profundizamos sobre esto.
Método 3: filtro PHP en wp-config.php
Agregás esta línea en wp-config.php, antes de /* That's all, stop editing! */:
add_filter('xmlrpc_enabled', '__return_false');Esto deshabilita XML-RPC dentro de WordPress. El problema: el archivo sigue siendo accesible, los bots siguen golpeando la URL, y el servidor procesa el request completo (carga PHP de WordPress incluida) para devolver un error al final. Reduce el daño pero no el consumo de CPU. Para bloqueo real a nivel de recursos, necesitás el método .htaccess o NGINX.
Método 4: plugin Disable XML-RPC
Si no querés tocar archivos del servidor, hay plugins en el repositorio oficial de WordPress específicos para esto. Instalás, activás, y el endpoint queda bloqueado. La desventaja: dependés de que el plugin esté siempre activo. Si alguien lo desactiva accidentalmente en una limpieza de plugins, xmlrpc.php vuelve a estar expuesto, sin aviso, sin log, sin que nadie se dé cuenta hasta que los bots empiecen de nuevo.
Método 5: Wordfence Firewall
Si ya tenés Wordfence instalado, esta es la opción más cómoda. En Wordfence > Firewall > Brute Force Protection encontrás opciones específicas para XML-RPC. Podés elegir entre bloquear solo la autenticación via XML-RPC o bloquear todo el tráfico al endpoint. La ventaja sobre .htaccess: lo configurás desde el admin de WordPress sin necesidad de acceso FTP o cPanel.
Cómo bloquear xmlrpc.php con Wordfence (paso a paso)
Asumiendo Wordfence instalado y activo en tu WordPress:
- Paso 1: Ir a Wordfence > Firewall en el menú lateral del admin.
- Paso 2: Dentro de Firewall, buscar la sección Brute Force Protection.
- Paso 3: Localizar las opciones de XML-RPC. Dependiendo de la versión de Wordfence, aparecen como «Disable WordPress XML-RPC authentication» o «Block all XML-RPC requests».
- Paso 4: Para bloqueo total, activar «Block all XML-RPC requests». Si tenés algún servicio que use XML-RPC para funciones no relacionadas con autenticación (poco probable pero posible), podés usar «Disable XML-RPC authentication» para bloquear solo el vector de fuerza bruta sin cerrar el endpoint por completo.
- Paso 5: Guardar cambios y verificar que el bloqueo funciona (ver la sección siguiente).
La diferencia entre las dos opciones importa: «Disable authentication» bloquea los métodos que requieren usuario y contraseña, pero el archivo sigue respondiendo requests que no necesitan autenticación. «Block all» cierra la puerta completamente. Para la gran mayoría de los sitios, «block all» es la respuesta correcta. Si alguien te dice que necesitás XML-RPC para algo específico, preguntale exactamente qué función y verificalo antes de reabrir.
Verificación: cómo confirmar que xmlrpc.php está bloqueado
Bloqueaste xmlrpc.php. ¿Funcionó? Hay tres formas de verificarlo.
Con curl desde la terminal
El método más directo y el que deberías hacer siempre después de cualquier cambio:
curl -v -X POST https://tudominio.com/xmlrpc.phpLo que esperás ver según el método de bloqueo:
- 403 Forbidden: bloqueo a nivel de servidor (.htaccess o NGINX). El request ni llega a WordPress. Esto es lo ideal.
- 404 Not Found: algunas configuraciones devuelven esto. Funcional, aunque menos informativo sobre la causa del bloqueo.
- XML con error de PHP: si usaste el filtro en wp-config.php, el servidor procesa el request y devuelve un XML de error de WordPress. El endpoint sigue cargando PHP, pero XML-RPC está deshabilitado dentro de la aplicación.
Lo que definitivamente no querés ver: una respuesta XML bien formada con una lista de métodos disponibles. Eso significa que xmlrpc.php está funcionando normalmente y tu bloqueo no tuvo efecto. Cubrimos ese tema en detalle en firewalls integrados de seguridad.
Revisando los logs de acceso
Si tenés acceso a los logs del servidor (cPanel > Logs de acceso, o SSH), buscá líneas que contengan «xmlrpc.php» y fijate el código de respuesta. Con bloqueo activo, deberías ver 403. Sin bloqueo, vas a ver 200 con bytes transferidos (el XML de respuesta). Esto también te da una idea del volumen de intentos que recibís.
Entrás al log por SSH, ejecutás algo como grep xmlrpc /var/log/nginx/access.log | tail -50 y ves el historial reciente. Si encontrás cientos de líneas con 403, el bloqueo funciona y los bots siguen intentando (sí, en serio: no paran, solo fracasan). Si encontrás líneas con 200, hay un problema.
Qué está confirmado y qué no sobre xmlrpc.php en 2026
| Afirmación | Estado |
|---|---|
| Los ataques automatizados a xmlrpc.php aumentaron en mayo 2026 | Confirmado — reportes de múltiples proveedores de hosting en la región |
| El método system.multicall permite amplificación de fuerza bruta | Confirmado — documentado por Wordfence desde 2015, sigue vigente |
| La app móvil de WordPress no necesita xmlrpc.php en versiones actuales | Confirmado — usa REST API desde WordPress 4.7 (diciembre 2016) |
| Jetpack no necesita xmlrpc.php en versiones recientes | Mayormente confirmado — verificar funciones específicas según versión instalada |
| Bloquear xmlrpc.php no rompe el funcionamiento normal del sitio | Confirmado para la mayoría de sitios — depende de integraciones de terceros activas |
| WordPress va a eliminar xmlrpc.php en versiones futuras | Pendiente — no hay anuncio oficial de deprecación al momento de publicación |
Errores comunes al bloquear xmlrpc.php
Error 1: usar el filtro PHP y creer que el problema está resuelto
El filtro add_filter('xmlrpc_enabled', '__return_false') deshabilita la funcionalidad de XML-RPC dentro de WordPress, pero el archivo sigue respondiendo requests. Subís la configuración, verificás que XML-RPC no funciona, cerrás el tema, y dos semanas después el hosting te avisa que el servidor tiene picos de CPU. Los bots siguen golpeando xmlrpc.php, el servidor procesa cada request con toda la carga de PHP y el stack de WordPress, y solo al final devuelve un error. Reducís el daño pero no el consumo de recursos. Para bloqueo real, necesitás .htaccess o NGINX.
Error 2: bloquear sin verificar integraciones activas
Bloqueás el archivo, todo parece funcionar, y a los cinco días descubrís que el sistema de respaldos automáticos a la nube dejó de funcionar porque usaba XML-RPC para conectarse. O que un plugin de publicación programada instalado en 2019 ya no puede sincronizar contenido con el calendario. Antes de bloquear, revisá los logs de acceso de los últimos 7 días y filtrá por solicitudes a xmlrpc.php con código 200 y user agents reconocibles. Si los únicos requests son de bots con user agents genéricos, cerrás sin riesgo. Si ves algo que no reconocés, investigalo antes.
Error 3: instalar un plugin específico para xmlrpc.php cuando ya tenés Wordfence
Si ya tenés Wordfence activo, no necesitás otro plugin solo para esto. La opción ya está integrada en Wordfence > Firewall > Brute Force Protection. Agregar plugins que duplican funcionalidad existente aumenta la superficie de ataque y el overhead de PHP en cada carga de página, que es exactamente lo contrario a lo que querés cuando estás optimizando la seguridad y el rendimiento del sitio.
Preguntas Frecuentes
¿Qué es xmlrpc.php en WordPress?
xmlrpc.php es un archivo incluido por defecto en todas las instalaciones de WordPress que implementa el protocolo XML-RPC, una forma de ejecutar llamadas remotas a través de HTTP. Fue diseñado para permitir que herramientas externas como aplicaciones móviles y clientes de blog de escritorio interactuaran con WordPress sin pasar por el panel de administración. Desde WordPress 4.7 (diciembre de 2016), la REST API reemplazó sus funciones principales y el archivo quedó como componente legacy activo por defecto.
¿Cómo bloquear xmlrpc.php sin romper mis plugins?
Antes de bloquear, revisá los logs de acceso de tu hosting para ver si algún plugin o servicio usa xmlrpc.php con código de respuesta 200 (exitoso). Si en los últimos 7 días no ves requests legítimos al archivo (solo bots y escaneos automáticos), podés bloquearlo con seguridad usando .htaccess o Wordfence. Si encontrás plugins que lo usan, verificá si tienen soporte para la REST API en sus versiones actuales; la mayoría de los plugins modernos migraron hace años. Más contexto en detección de vulnerabilidades.
¿Afecta el bloqueo de xmlrpc.php a la app móvil de WordPress?
No afecta las versiones actuales. La app móvil oficial de WordPress usa la REST API desde WordPress 4.7 (diciembre de 2016). Si usás la app actualizada en 2026, no necesita xmlrpc.php para nada: publicar, editar, moderar comentarios y gestionar el sitio funcionan via REST API. Solo afectaría si tenés una versión de la app que no actualizás desde antes de 2017, escenario que es prácticamente imposible en dispositivos modernos.
¿Necesito xmlrpc.php para Jetpack?
Las versiones recientes de Jetpack usan la REST API para sus funciones principales. Sin embargo, algunas funciones específicas de sincronización pueden tener comportamientos distintos según la versión de Jetpack instalada. Si usás Jetpack y querés hacer un bloqueo total de xmlrpc.php, el camino más seguro es usar la opción «Disable XML-RPC authentication» de Wordfence en vez de bloqueo total, o verificar directamente con el soporte de Jetpack qué funciones activas en tu instalación dependen del protocolo.
¿Cuál es la mejor forma de proteger xmlrpc.php?
Para la mayoría de los sitios, el bloqueo total a nivel de servidor usando .htaccess (hosting Apache) o la configuración de NGINX es la opción más eficiente: corta el problema antes de que PHP procese el request, sin overhead de aplicación. Si ya tenés Wordfence, la opción «Block all XML-RPC requests» en Brute Force Protection logra el mismo resultado desde el admin de WordPress, sin tocar archivos del servidor. Ambos métodos devuelven un 403 Forbidden que los bots procesan y abandonan sin consumir recursos adicionales.
Conclusión
xmlrpc.php es uno de esos problemas de WordPress que existe hace más de una década y que en 2026 sigue siendo relevante porque la mayoría de los sitios nunca lo cerraron. El vector de amplificación via system.multicall está documentado desde 2015, los ataques de mayo de 2026 muestran que los bots siguen aprovechándolo, y el archivo sigue activo por defecto en cada instalación nueva de WordPress.
La buena noticia: bloquearlo es directo. Si usás hosting Apache, el método con .htaccess es de cinco minutos. Si tenés Wordfence, la opción está en el panel sin necesidad de tocar archivos del servidor. Si tenés un VPS con NGINX, dos líneas en la configuración resuelven el problema de forma definitiva.
Antes de hacer cualquier cosa: revisá los logs. Entrás al cPanel, abrís los logs de acceso, buscás «xmlrpc» y ves qué hay. Si solo encontrás bots con user agents genéricos y request POST a deshora, bloquealo hoy. Si encontrás requests de servicios que reconocés, investigalos primero. El bloqueo sin verificación previa puede romper integraciones que funcionan en silencio hace años y que nadie recuerda haber configurado.
Y si el hosting empieza a avisarte por picos de CPU inexplicables en tu sitio WordPress, mirá xmlrpc.php primero. Es la causa más frecuente y la más fácil de cerrar.