XML-RPC es un protocolo heredado de WordPress que permite conexiones remotas a tu sitio, pero sin protección contra ataques de fuerza bruta ni DDoS. La mayoría de sitios modernos no lo necesitan desde que WordPress incorporó REST API, pero sigue activo por defecto en toda instalación, exponiendo tu sitio a combinaciones username/password sin límite de intentos y a ataques de pingback que saturan tu servidor. Desactivarlo es tan simple como instalar un plugin (o editar .htaccess) y mejora tanto seguridad como rendimiento sin afectar ningún sitio moderno.
En 30 segundos
- XML-RPC es un protocolo que permite apps externas conectarse a tu WordPress sin pasar por el login estándar, sin protección contra ataques de fuerza bruta.
- Los atacantes usan xmlrpc.php para enviar miles de combinaciones username/password sin que se dispare bloqueo de cuenta.
- Pingback abuse: explotación del método pingback.ping para saturar servidores con solicitudes DDoS masivas.
- La REST API moderna reemplazó XML-RPC en 2016, así que 99% de sitios no lo necesita (excepto Jetpack u apps legacy).
- Desactívalo con plugin (Disable XML-RPC), .htaccess, o filtro PHP — cero impacto en sitios modernos, mejora de seguridad inmediata.
XML-RPC WordPress es un protocolo de llamadas remotas que WordPress integra para permitir la comunicación entre aplicaciones externas y un sitio WordPress. Fue implementado para facilitar la publicación remota de artículos y el acceso a funcionalidades del blog desde clientes de terceros.
¿Qué es XML-RPC en WordPress?
XML-RPC es un protocolo de llamadas remotas que permite a aplicaciones externas comunicarse con tu WordPress sin necesidad de acceder a la interfaz gráfica del sitio. Viene de los tiempos de b2 (el antecesor de WordPress), cuando las apps móviles y los blogs remotos necesitaban una forma de publicar contenido sin cargar wp-admin. WordPress activó XML-RPC por defecto desde la versión 3.5 (2012), y sigue así hasta hoy.
El endpoint está en /xmlrpc.php — una puerta trasera que responde a métodos como wp.getUsersBlogs, wp.newPost, pingback.ping. Ponele que Jetpack o una app móvil antigua necesita publicar un post: en vez de usar REST API (que es lo que hace ahora), mandaba credenciales a XML-RPC y listo. (Spoiler: nadie usa esto hace años.)
La verdad es que REST API, introducida formalmente en WordPress 4.7 (enero 2017), reemplazó completamente a XML-RPC. Las credenciales, la seguridad, la estructura de respuestas — todo es moderno. Pero ojo: XML-RPC sigue habilitado en toda instalación nueva, como un fantasma de la era anterior a REST API que nadie desactivó.
Riesgos de seguridad: Ataques de fuerza bruta
Acá viene lo bueno. El método wp.getUsersBlogs expone un endpoint de autenticación que carece de rate limiting. Mientras que el login estándar (wp-login.php) dispara bloqueos de cuenta después de 5 intentos fallidos, XML-RPC acepta miles de combinaciones username/password sin restricción alguna. Complementá con métodos seguros de automatización.
Un atacante puede escribir un script que, en minutos, envía 10.000 intentos contra tu sitio combinando diccionarios de usuarios (admin, administrator, ariel, etc.) con passwords comunes. Según WPScan, esto es particularmente efectivo contra sitios que no han actualizado credenciales por defecto — que, desgraciadamente, son muchos.
El lado feo: con XML-RPC no hay protección. No hay CAPTCHA, no hay bloqueo por IP, no hay alerta de Wordfence (depende de la configuración, pero el paquete XML-RPC viaja diferente al login web). Un bot puede probar millones de combinaciones contra tu sitio sin que lo notices hasta que alguien cambió tu contraseña o agregó un usuario admin nuevo.
Ataques DDoS a través de XML-RPC
El segundo riesgo, más crítico aún, es pingback abuse. El método pingback.ping permite a cualquiera notificar a tu sitio que otra página menciona un post tuyo. Es útil para trackbacks entre blogs (es de 2005, básicamente), pero también es un arma perfecta para DDoS.
Un atacante explota esto así: obtiene tu URL de post, escribe un script que envía miles de solicitudes de pingback falsas a la misma URL desde direcciones IP distribuidas, tu servidor intenta verificar cada pingback (conecta a la URL origen, descarga el contenido), consume CPU/RAM masivamente, tu sitio se ralentiza o cae. Según AyudaWP, esto es especialmente grave en shared hosting donde compartís recursos con otros sitios.
Lo peor: el atacante no necesita credenciales. No necesita romper nada. Simplemente explota un método que, por defecto, está ahí, abierto para cualquiera.
Otras vulnerabilidades: IP Disclosure y ejecución remota de código
Más allá de fuerza bruta y DDoS, XML-RPC introduce otros riesgos menores pero reales:
IP Disclosure: Si tu sitio está detrás de un WAF (como Cloudflare) o un proxy, XML-RPC puede filtrar tu IP real porque el protocolo responde de formas que un WAF tradicional no filtra tan bien. Patchstack documenta esto como issue recurrente en auditorías.
Malware moderno: Algunos troyanos WordPress usan XML-RPC para cambiar configuraciones del sitio (agregar usuarios, cambiar URLs, instalar plugins) sin necesidad de acceso vía wp-admin. Si tu sitio está comprometido, XML-RPC da al atacante un canal extra para hacer movimientos post-explotación. Más contexto en extensiones de WordPress confiables.
3 métodos para desactivar XML-RPC
La buena noticia: desactivar XML-RPC es trivial. Tres opciones, de menos a más técnico:
| Método | Dificultad | Reversible | Mejor para |
|---|---|---|---|
| Plugin (Disable XML-RPC) | Nula | Sí | Principiantes, shared hosting |
| .htaccess | Baja | Sí | Sitios con Apache, quieren no plugins |
| Code Snippets o functions.php | Media | Sí (si editás con cuidado) | Developers, quieren mínimo overhead |
Opción 1: Plugin (recomendado)
Instalá Disable XML-RPC o Stop XML-RPC Attack desde el repositorio oficial de WordPress. Activá, listo. El plugin bloquea el endpoint retornando un error 403 a cualquier solicitud a /xmlrpc.php. Cero configuración, cero riesgo, reversible en un click.
Opción 2: .htaccess (si usás Apache)
Agregá esto al inicio de tu .htaccess en la raíz de tu sitio (hacé backup primero):
# Block WordPress xmlrpc.php requests
<Files xmlrpc.php>
order deny,allow
deny from all
</Files>
Guardá, probá visitando tudominio.com/xmlrpc.php en el navegador — deberías ver un error 403. Cubrimos ese tema en detalle en soluciones de firewall para WordPress.
Opción 3: Code Snippets o functions.php
Si querés hacerlo por código, agregá esto a tu functions.php (o mejor, usa Code Snippets para no editar el theme):
add_filter('xmlrpc_enabled', '__return_false');
Esto desactiva XML-RPC a nivel de WordPress — más elegante que bloquear a nivel HTTP, porque respeta mejor los hooks de WordPress.
¿Debería desactivar XML-RPC?
Sí, casi con toda seguridad. A menos que estés usando Jetpack (que aún se conecta vía XML-RPC en algunos casos legacy), o una app móvil de 2010 que dependa de este protocolo, no lo necesitás. REST API reemplazó completamente esta funcionalidad desde hace casi una década.
Impacto de desactivarlo: cero. Tu sitio sigue funcionando igual, emails llegan igual, cachés se refrescan igual. Lo que cambias es que eliminás un vector de ataque completamente innecesario.
¿Cómo verificar si algo depende de XML-RPC? Antes de desactivarlo, revisá los logs de tu servidor durante una semana. Si ves solicitudes a /xmlrpc.php que NO son ataques (User-Agent legítimo, no combinaciones username/password), entonces algo lo está usando. Si no ves nada, descactivalo sin dudas.
Implementación segura: paso a paso
Subís el modelo, lo probás en local, funciona bárbaro, lo mandás a producción y de repente todo se rompe porque alguien depende de XML-RPC — así que acá está el flujo seguro: Esto se conecta con lo que analizamos en herramientas de edición alternativas.
- Paso 1: Hacé un backup completo (WPVivid, UpdraftPlus, lo que uses). Esto no es paranoia, es profesionalismo.
- Paso 2: Revisá los logs de acceso (
access.log) durante los últimos 7 días. Buscá solicitudes axmlrpc.phpque NO sean ataques de fuerza bruta (es decir, User-Agent legítimo, sin diccionarios de passwords). Si las hay, investigá qué las causa antes de desactivar. - Paso 3: Elegí tu método (plugin es lo más seguro). Instalá/configurá.
- Paso 4: Probá en el navegador: visitá
tudominio.com/xmlrpc.php. Deberías ver error 403, 404, o un mensaje de «disabled». Si ves respuesta XML normal, algo falló. - Paso 5: Monitorá Wordfence, el access.log, o lo que uses para detectar ataques. Deberías ver menos intentos de fuerza bruta después de unas horas.
- Paso 6: Siéntete seguro sabiendo que eliminaste un vector innecesario.
Errores comunes
Error 1: «Desactivé XML-RPC y ahora Jetpack no funciona»
Jetpack moderno usa REST API, no XML-RPC. Si algo se rompió después de desactivar, es probable que sea otra cosa. Verificá: revisá los logs de Jetpack en wp-admin, probá re-autenticar el sitio con Jetpack.com, o contactá al soporte. XML-RPC no es el culpable en 99% de casos. Cobertura relacionada: herramientas gratuitas recomendadas.
Error 2: Bloqueé XML-RPC con .htaccess pero los ataques no pararon
El bloqueo a nivel .htaccess evita que llegue al código, pero sigue consumiendo recursos porque el servidor sigue procesando la solicitud (retorna 403). Si los ataques son masivos, quizá necesitás un nivel extra de defensa: WAF (Cloudflare, Wordfence Premium), rate limiting en nginx, o bloqueos de IP a nivel servidor. XML-RPC es un paso, no la solución completa si tenés DDoS orquestado. Ampliamos el tema en integración segura con herramientas modernas.
Error 3: «Agregué el filtro a functions.php pero sigo viendo solicitudes a xmlrpc.php»
El filtro add_filter('xmlrpc_enabled', '__return_false') desactiva XML-RPC a nivel de WordPress, pero el archivo xmlrpc.php sigue respondiendo en algunos casos. Para bloqueo verdadero a nivel HTTP (más seguro), combiná el filtro con un bloqueo en .htaccess. O usá un plugin que maneje ambos.
Preguntas Frecuentes
¿Qué es exactamente XML-RPC en WordPress?
Es un protocolo que permite a aplicaciones externas (apps móviles, bots, servicios remotos) conectarse a tu WordPress y ejecutar acciones como publicar posts, cambiar configuraciones, o enviar pingbacks — sin pasar por wp-admin. Viene del año 2005, es heredado, y REST API lo reemplazó completamente hace casi 10 años.
¿Cuáles son los riesgos principales de seguridad de XML-RPC?
Tres: (1) ataques de fuerza bruta sin rate limiting, permitiendo intentos ilimitados de username/password; (2) pingback abuse, donde atacantes exploit pingback.ping para DDoS masivo; (3) filtración de IP si estás detrás de WAF, y uso por malware post-compromiso. Según Kinsta, los ataques vía XML-RPC son consistentes en reportes de seguridad WordPress.
¿Afecta desactivar XML-RPC a mi sitio?
No. Prácticamente ningún sitio moderno usa XML-RPC. REST API (desde WordPress 4.7, 2017) reemplazó esta funcionalidad completamente. Si usás Jetpack, plugins respaldados, o apps móviles de este siglo, seguirán funcionando. Desactívalo sin miedo.
¿Cuál es el mejor método para desactivar XML-RPC?
Plugin (Disable XML-RPC o Stop XML-RPC Attack). No requiere editar archivos, es reversible en un click, y maneja todo a nivel WordPress. Si preferís no agregar plugins, usa .htaccess. Si sos developer, usa el filtro + Code Snippets.
¿Cómo verifico si desactivé XML-RPC correctamente?
Visitá tudominio.com/xmlrpc.php en el navegador. Si ves error 403, 404, o un mensaje «XML-RPC disabled», está bloqueado. Si ves XML bien formado o un menu de métodos disponibles, no está desactivado aún. También podés revisar los logs: si desaparecen solicitudes a xmlrpc.php en los próximos días, es señal de que los atacantes se dieron por vencidos.
Conclusión
XML-RPC es un protocolo heredado que sigue activo en WordPress por compatibilidad hacia atrás, pero ningún sitio moderno lo necesita. REST API es el estándar desde 2017, más seguro, más eficiente, mejor documentado. Mantener XML-RPC habilitado es como dejar una puerta trasera abierta en tu casa por si alguien quiere entrar por ahí alguna vez — en teoría alguien podría necesitarlo, en la práctica nadie, y mientras tanto tus ataques de fuerza bruta y DDoS usan esa puerta sin restricción.
Desactivarlo tarda 30 segundos con un plugin, no afecta nada funcional, y mejora tu seguridad y rendimiento inmediatamente. Si aún no lo hiciste, ahora es un buen momento. Ponele.