XML-RPC en WordPress: Guía de Seguridad 2026

Si tenés WordPress, seguro viste el archivo xmlrpc.php en los logs de acceso. Deshabilitar XML-RPC en 2026 sigue siendo una de las medidas de hardening más efectivas y baratas (gratis, literal) que podés aplicar. Lo desactivás con un plugin en menos de dos minutos, con tres líneas en .htaccess o con un filtro si te animás a tocar código. El resultado: bloqueás ataques de fuerza bruta, amplificación DDoS y consumo fantasma de recursos que no necesitás.

XML-RPC es un protocolo de comunicación remota que WordPress activa por defecto desde sus primeras versiones para permitir publicar contenido desde apps móviles, habilitar pingbacks y trackbacks, y conectarse con herramientas externas. Aunque desde 2017 la REST API ofrece una alternativa más segura y moderna, xmlrpc.php sigue presente en millones de instalaciones como un legado que pocos usan pero muchos atacan.

¿Qué es XML-RPC y por qué sigue activo en WordPress?

XML-RPC (XML Remote Procedure Call) es un protocolo que permite a sistemas externos ejecutar funciones en tu WordPress usando peticiones HTTP POST. Nació con WordPress 1.0, cuando todavía era un bloguero y no un CMS completo, y era la única forma de publicar desde afuera sin tocar el panel de administración. Hoy, en 2026, sigue activo por defecto —por pura compatibilidad hacia atrás— aunque ya nadie lo use. La REST API, presente desde WordPress 4.7 (diciembre de 2016), cubre todas esas funciones con autenticación moderna, OAuth y JSON, pero xmlrpc.php quedó como un apéndice que la mayoría de los sitios no necesita.

El problema es que, como viene habilitado de fábrica, se convierte en un blanco fácil. Los atacantes escanean /xmlrpc.php automáticamente porque saben que ahí pueden probar credenciales sin límite. Y si bien algunos plugins viejos o configuraciones muy específicas podrían esperar que esté activo, en la práctica diaria de mantenimiento de sitios en 2026, la pregunta no es «¿para qué lo necesito?» sino «¿por qué sigue encendido?». Cuando arrancaste con WordPress hace quince años, capaz usabas la app móvil antigua que dependía de XML-RPC para publicar desde el bondi, pero eso cambió, las apps modernas migraron a REST hace años y hoy ni te enterás de que ese archivo existe hasta que un pico de CPU o un aviso de hosting te lo señalan.

Riesgos de seguridad de mantener XML-RPC activo

Acá viene lo bueno. El riesgo principal no es teórico: es fuerza bruta sin throttling. Cuando un atacante apunta a xmlrpc.php, puede usar el método system.multicall para meter decenas o cientos de intentos de login en un solo request HTTP. Sin límite de peticiones por minuto por IP, y sin los nonces o protecciones que tiene wp-login.php. En la práctica, según análisis de Seguridad en WordPress, los logs de servidores muestran oleadas de estos ataques automatizados que pueden tumbar un shared hosting modesto en cuestión de minutos.

Ponele que tenés un sitio de noticias con 50.000 visitas mensuales. Un sábado a la madrugada tu servidor empieza a arrastrarse, y cuando revisás los logs, todo es POST a xmlrpc.php. ¿Adiviná de dónde vienen? De una botnet que está probando usuarios y contraseñas usando system.multicall sin límite de intentos por minuto. (Sí, en serio, un solo request puede meter cientos de combinaciones.)

El segundo problema son los pingbacks y trackbacks. Originalmente pensados para notificar enlaces entre blogs, hoy son un vector de amplificación DDoS: un atacante manda un pingback falso desde miles de sitios y tu WordPress les responde a todos, multiplicando el tráfico. Incluso si vos no habilitaste pingbacks, el endpoint sigue escuchando. Y ni hablar del consumo de recursos: cada request a xmlrpc.php carga WordPress completo, así que un ataque sostenido te come CPU y RAM como si estuvieras sirviendo visitas reales. Te puede servir nuestra cobertura de nuestra guía completa sobre CVE en WordPress.

¿Qué funcionalidades se pierden al desactivar XML-RPC?

La respuesta corta: casi nada. La respuesta larga: depende de si tu stack es lo suficientemente moderno para usar REST API, y en 2026, prácticamente todo lo es. Jetpack, el plugin de Automattic, migró su comunicación a REST API en la versión 7.0 (2019) y desde entonces no necesita xmlrpc.php. Las apps oficiales de WordPress para iOS y Android también usan REST. Herramientas como IFTTT o Zapier se conectan mediante REST o webhooks, no XML-RPC.

Si tenés un plugin muy viejo o un tema comprado hace una década que hace peticiones XML-RPC, podrías notar que alguna funcionalidad deja de andar. Pero si un plugin no se actualizó desde 2017, el problema no es XML-RPC: es que estás usando software abandonado. Lo que sí conviene hacer antes de deshabilitarlo es revisar los logs de acceso durante una semana para ver si alguna herramienta legítima lo está usando. En el 99% de los casos, los únicos requests a xmlrpc.php vienen de scanners de vulnerabilidades o de bots malintencionados.

Método 1: Desactivar XML-RPC con plugin (recomendado)

Para la mayoría de los administradores de WordPress, este es el camino. Vas al repositorio oficial, buscás «Disable XML-RPC» o «Stop XML-RPC Attack», instalás y activás. No hay ajustes que tocar: el plugin intercepta las peticiones a xmlrpc.php y devuelve un error 403 Forbidden. Punto. Si en algún momento necesitás revertirlo, desactivás el plugin y listo.

¿Qué plugin elegir? Cualquiera de los dos que mencioné tiene más de 100.000 instalaciones activas y se actualiza con regularidad. Disable XML-RPC es el más simple: un solo archivo, cero overhead, hace exactamente lo que dice. Stop XML-RPC Attack agrega un firewall mínimo que bloquea también otras peticiones maliciosas si querés algo un poco más completo. Ambos gratuitos y livianos. (Ojo: no instales múltiples plugins de seguridad que hagan lo mismo porque pueden pisarse y generar conflictos.)

Una vez activado, verificá: entrá a tudominio.com/xmlrpc.php y deberías ver un mensaje «403 Forbidden» o similar. Si ves un error de WordPress o un listado de métodos XML, el plugin no está funcionando. Sobre eso hablamos en te recomendamos revisar esta guía de WAF para WordPress.

Método 2: Desactivar XML-RPC editando .htaccess

Si preferís no sumar plugins, podés bloquear el acceso a nivel de servidor web. Editás el archivo .htaccess de la raíz de WordPress y agregás al principio:

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

Esta regla funciona en Apache 2.4+. Si tu hosting todavía usa Apache 2.2 (cada vez más raro en 2026, pero existen), usarías:

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

En Nginx la cosa cambia: tenés que agregar en el bloque server de tu configuración:

location = /xmlrpc.php {
 deny all;
 return 403;
}

La ventaja es que no cargás WordPress: el servidor web rechaza la petición antes de llegar al PHP, así que ahorrás recursos. La desventaja es que si migrás de servidor o restaurás un backup, podés olvidarte de volver a aplicar el bloqueo. Documentalo en tu checklist de despliegue.

Método 3: Desactivar XML-RPC mediante filtro de WordPress

Para los que se sienten cómodos con código, WordPress tiene un filtro específico desde la versión 3.5 (2012) que es xmlrpc_enabled. Agregás una línea en functions.php de tu tema hijo o, mejor, mediante un plugin de snippets como Code Snippets (así no se te borra al cambiar de tema): Cubrimos ese tema en detalle en más detalles sobre protección DDoS en WordPress.

add_filter('xmlrpc_enabled', '__return_false');

Esto le dice a WordPress «XML-RPC no existe». El endpoint sigue estando técnicamente accesible, pero WordPress devuelve un error controlado sin exponer los métodos. Es la forma más limpia a nivel de aplicación: no requiere tocar el servidor ni instalar plugins de terceros. Si sos developer y manejás varios sitios, podés meterlo en un mu-plugin (must-use plugin) para que sea inmune a cambios de temas y desactivaciones accidentales. La contra: si por algún motivo necesitás habilitarlo temporalmente, tenés que editar el código.

Comparativa de métodos para desactivar XML-RPC

En 2026, el método con .htaccess o Nginx es el más eficiente para sitios con alto tráfico, pero el plugin es imbatible en simplicidad. Si estás en un hosting administrado como donweb.com, su soporte técnico puede aplicar el bloqueo a nivel servidor por vos si lo pedís — muchos proveedores ya incluyen reglas de hardening para xmlrpc.php en sus configuraciones por defecto, pero siempre conviene verificarlo.

Medidas adicionales de hardening para xmlrpc.php y REST API

Desactivar XML-RPC es el primer paso, pero no el único. Si querés dormir tranquilo, aplicá estas prácticas complementarias que cierran otros flancos:

• Desactivá pingbacks y trackbacks desde Ajustes > Discusión en el panel de WordPress. Aunque bloquees xmlrpc.php, los pingbacks pueden intentar usar otras vías o plugins que implementen su propio endpoint. Mejor cortarlos de raíz.
• Aplicá rate limiting con fail2ban o mod_evasive para peticiones repetidas a wp-login.php y a la REST API si la mantenés pública. Así evitás fuerza bruta contra otros vectores.
• Versioná y protegé la REST API: si exponés endpoints personalizados, usá autenticación nonce o OAuth y versionado (/wp-json/miapp/v1/). Habilitá CORS solo para los orígenes que realmente necesitás, no con wildcard.
• Usá un proxy API personalizado si tu sitio es headless o consume datos desde un frontend separado. Así centralizás la seguridad y no exponés la REST API nativa de WordPress directamente.
• Monitoreá logs con herramientas como WP Activity Log o Elastic Stack. Si alguien golpea xmlrpc.php después de desactivarlo, al menos sabés que hay intentos.

El punto es que en 2026, la seguridad de WordPress no depende de una sola medida, sino de capas. XML-RPC es la más obvia para atacar por inercia, pero cerrar ese agujero sin hacer nada más es como poner rejas en la ventana del baño y dejar la puerta de calle sin llave.

Si querés más detalles sobre esto, tenemos un artículo dedicado a desactivar XML-RPC.

Si querés profundizar, tenemos un artículo sobre proteger xmlrpc.php.

Errores comunes al desactivar XML-RPC (y cómo evitarlos)

• Creer que Jetpack o la app móvil van a fallar. Como ya aclaré, Jetpack usa REST API desde 2019 y las apps móviles oficiales también. Si después de desactivar XML-RPC notás que Jetpack se desconecta, revisá que esté actualizado y reautenticalo. No es culpa de XML-RPC, es una sesión expirada.
• Olvidarse de los pingbacks. Bloqueaste xmlrpc.php pero en Ajustes > Discusión seguís permitiendo notificaciones de enlaces. Aunque el endpoint esté muerto, tu sitio puede seguir generando tráfico saliente o procesando pings de otras fuentes. Desmarcá esa opción y asegurate de que ningún plugin la rehabilite.
• No verificar que el bloqueo funciona. Aplicaste el filtro en functions.php, guardaste, y te olvidaste. Siempre, siempre, probá entrar a /xmlrpc.php con el navegador o con curl. Si ves algo que no sea un 403 o un error deshabilitado, el bloqueo no está funcionando.
• Usar el filtro en un tema que se actualiza. Si ponés el código en el functions.php del tema principal y después actualizás el tema, perdés el filtro. Usá un tema hijo, un plugin de snippets o un mu-plugin. Es el error más frecuente entre quienes recién arrancan con personalizaciones.
• Desactivar XML-RPC sin monitoreo posterior. Una vez bloqueado, algunos administradores se relajan y dejan de mirar los logs. Pero los ataques no se detienen: siguen llegando peticiones que ahora son rechazadas. Monitoreá para saber si el volumen de intentos es anormal y tomar medidas adicionales de firewall.

Preguntas Frecuentes

¿Cómo desactivar XML-RPC en WordPress?

Podés desactivarlo con un plugin gratuito como «Disable XML-RPC», editando el archivo .htaccess para denegar el acceso al archivo xmlrpc.php, o mediante un filtro en el código de WordPress usando add_filter('xmlrpc_enabled', '__return_false');. El método con plugin es el más simple y reversible.

¿Es seguro desactivar XML-RPC?

Sí, es seguro en la gran mayoría de los sitios WordPress modernos (2026). La REST API cubre las funciones que antes dependían de XML-RPC, como la conexión con apps móviles o Jetpack. Antes de desactivarlo, conviene revisar los logs para asegurarse de que ninguna herramienta legítima lo esté usando. Complementá con descubrí cómo WPForms mejora la seguridad del sitio.

¿Qué riesgos tiene tener XML-RPC activado?

Los riesgos principales son ataques de fuerza bruta sin límite de intentos (usando system.multicall), amplificación DDoS mediante pingbacks y consumo excesivo de recursos del servidor. Es uno de los endpoints más atacados en WordPress, junto con wp-login.php y la REST API desprotegida.

¿XML-RPC afecta el rendimiento del sitio?

Por sí mismo, si no recibe tráfico malicioso, no afecta. Pero cuando es blanco de ataques, cada petición carga el núcleo completo de WordPress, lo que puede saturar la CPU y la memoria del servidor. Desactivarlo elimina esa carga potencial y mejora la estabilidad general del sitio.

¿Jetpack necesita XML-RPC?

No, desde la versión 7.0 (lanzada en 2019), Jetpack se comunica exclusivamente mediante la REST API de WordPress. Desactivar XML-RPC no afecta el funcionamiento de Jetpack ni su capacidad de conectar con WordPress.com.

Conclusión

Deshabilitar XML-RPC en WordPress en 2026 es una de esas tareas de mantenimiento que deberían ser automáticas, como actualizar plugins o cambiar las contraseñas cada tanto. Lleva dos minutos, no cuesta un peso y cierra un vector de ataque que los bots escanean las 24 horas. Si tu sitio corre con un stack actualizado —y debería, hablamos de 2026—, no perdés ninguna funcionalidad real, ganás en seguridad y le bajás el ruido a los logs.

La pregunta no es si conviene hacerlo. La pregunta es por qué WordPress todavía no lo desactiva por defecto. Mientras eso no cambie, la responsabilidad es tuya. Elegí el método que más te acomode, verificá que funcione y sumalo a tu checklist de hardening. Tu servidor (y tu yo del futuro a las 3 AM cuando suene una alerta) te lo van a agradecer.

Fuentes

• Seguridad en WordPress – XML-RPC: riesgos y cómo desactivarlo
• AWP Agency – Guía completa 2026 para desactivar XML-RPC
• WPDirecto – Mejores prácticas para configuración de xmlrpc.php y REST API
• WordPress REST API Handbook