Su sitio va lento, su proveedor de hosting le envía advertencias sobre límites excedidos y los registros muestran un flujo interminable de solicitudes POST a xmlrpc.php. Si usted administra WordPress, esta pesadilla probablemente le resulte familiar.

El archivo xmlrpc.php es un elemento silencioso pero extremadamente peligroso de cualquier instalación de WordPress. Ha vivido en la raíz de su sitio desde la instalación del CMS y ha sido un punto de entrada favorito para bots y atacantes durante décadas. Según el informe Wordfence de 2024, los ataques XML-RPC se encuentran entre los cinco principales vectores de amenaza para sitios WordPress, y nada ha cambiado en 2026.

Sin embargo, la mayoría de los propietarios de sitios no tienen idea de por qué existe este archivo o cómo neutralizarlo. Esta guía cubre cuatro métodos funcionales para bloquear xmlrpc.php, desde una regla rápida en .htaccess hasta un firewall a nivel de CDN. Sin relleno, solo código probado y explicaciones de cuándo usar cada método.

💡 Resumen rápido:

• Verifique si su xmlrpc.php responde a solicitudes POST (probablemente lo haga)
• Elija un método de bloqueo: htaccess, código en functions.php, plugin o WAF
• Agregue la regla de bloqueo y verifique que el endpoint devuelva 403 Forbidden
• Si usa Jetpack, configure protección de firewall dirigida en lugar de deshabilitarlo por completo

Qué es xmlrpc.php y por qué sigue en WordPress

XML-RPC (Remote Procedure Call) es un protocolo que permite a aplicaciones externas comunicarse con WordPress. Se agregó al núcleo en la versión 1.5 y sirvió durante décadas como la única API para publicación remota: las aplicaciones móviles de WordPress, clientes de escritorio como Windows Live Writer y servicios de terceros dependían de él.

Con el lanzamiento de la API REST de WordPress en la versión 4.7 (2016), la necesidad de XML-RPC desapareció en gran medida. La API REST moderna cubre todo lo que XML-RPC solía hacer, y lo hace de forma más segura, más rápida y con autenticación adecuada mediante nonce u OAuth.

Pero el archivo xmlrpc.php todavía se encuentra en la raíz de cada instalación de WordPress. La publicación remota a través de él está deshabilitada por defecto, sin embargo, el endpoint acepta solicitudes. Simplemente abra yoursite.com/xmlrpc.php en un navegador para ver: «XML-RPC server accepts POST requests only». Esto significa que el endpoint está activo y listo para ser atacado.

Por qué xmlrpc.php es peligroso: principales vectores de ataque

Los atacantes usan xmlrpc.php para dos tipos principales de ataques, y ambos pueden tumbar su sitio.

Fuerza bruta mediante system.multicall. El método system.multicall permite empaquetar cientos de intentos de autenticación en UNA sola solicitud HTTP. En lugar de probar contraseñas una por una (como a través de wp-login.php), un bot envía un array de inicios de sesión y contraseñas de una vez. Los plugins limitadores de inicio de sesión estándar no detectan tales solicitudes, para ellos parece «un intento». Resultado: los atacantes prueban miles de combinaciones en segundos sin activar bloqueos.

DDoS de Pingback. La función de pingback permite que otro sitio notifique a su WordPress sobre un enlace hacia él. Un atacante envía una solicitud de pingback falsificada, sustituyendo la dirección IP de la víctima como el «origen». Su servidor obedientemente va a verificar el enlace y ataca a un host objetivo desprevenido. Escale esto a través de miles de instalaciones de WordPress comprometidas y obtendrá un ataque DDoS distribuido donde su sitio sirve como carne de cañón.

Los proveedores de hosting rastrean el tráfico saliente de este tipo y pueden congelar su cuenta por «participar en DDoS». Mientras tanto, su servidor desperdicia CPU, memoria y ancho de banda atendiendo solicitudes basura.

Verifique: ¿responde su xmlrpc.php?

Antes de bloquear, asegúrese de que el endpoint esté realmente abierto. Abra esto en su navegador:

1
https://yoursite.com/xmlrpc.php

Si ve la cadena «XML-RPC server accepts POST requests only», el endpoint está activo y los atacantes pueden enviarle solicitudes. Si obtiene 403 Forbidden o 404, la protección ya está funcionando.

Segundo método: envíe una solicitud POST de prueba a través del terminal:

1
curl -X POST https://yoursite.com/xmlrpc.php -d '<methodCall><methodName>demo.sayHello</methodName></methodCall>'

Una respuesta con 200 OK y una estructura XML confirma: XML-RPC acepta solicitudes y está listo para ser explotado.

Método 1: bloqueo rápido vía.htaccess

El método más simple y efectivo es bloquear el acceso al archivo a nivel del servidor web. La solicitud se rechaza antes de que llegue a WordPress, lo que ahorra recursos del servidor y funciona incluso si el sitio está bajo carga.

Agregue esto a su .htaccess raíz (el que está junto a wp-config.php):

1
Block xmlrpc.php — protection from brute force and DDoS
2
<Files "xmlrpc.php">
3
    Require all denied
4
</Files>

La directiva Require all denied es sintaxis de Apache 2.4+, vigente para todos los proveedores de hosting modernos. Después de guardar, abra xmlrpc.php en su navegador; debería obtener 403 Forbidden.

Si su servidor ejecuta nginx, agregue la regla a la configuración del host virtual:

1
location = /xmlrpc.php {
2
    deny all;
3
    return 403;
4
}

Después de cambiar la configuración de nginx, recuerde recargar el servidor: sudo nginx -s reload.

Este método funciona si usted DEFINITIVAMENTE no necesita XML-RPC, ni para Jetpack, ni para las aplicaciones móviles de WordPress, ni para integraciones de WooCommerce.

Método 2: deshabilitar mediante functions.php (método programático)

Si prefiere resolver el problema a nivel de código en lugar de configuraciones de servidor, aquí tiene dos fragmentos probados para el functions.php de su tema activo o Code Snippets.

Deshabilitar XML-RPC por completo (WP 3.5+):

1
// Disable XML-RPC completely
2
add_filter('xmlrpc_enabled', '__return_false');

Una línea, y WordPress deja de procesar cualquier solicitud XML-RPC. Al intentar acceder a xmlrpc.php, el cliente recibe una respuesta de error; el archivo en sí permanece en el servidor pero está funcionalmente muerto.

Limpiar los encabezados wp_head de los enlaces RSD y WLW:

Incluso después de deshabilitar XML-RPC WordPress continúa insertando dos líneas en <head> que revelan información sobre su sitio:

1
// Remove RSD and WLW Manifest links from headers
2
function sd_remove_xmlrpc_headers() {
3
    remove_action('wp_head', 'rsd_link');
4
    remove_action('wp_head', 'wlwmanifest_link');
5
}
6
add_action('init', 'sd_remove_xmlrpc_headers');

Los hooks rsd_link y wlwmanifest_link agregan las etiquetas <link rel="EditURI"> y <link rel="wlwmanifest"> a <head>; estas existen exclusivamente para clientes XML-RPC y no tienen ningún propósito práctico en 2026. Elimínelas.

⚠️ Importante: las ediciones en el functions.php del tema se perderán al actualizar. Use un tema hijo o el plugin Code Snippets para almacenar código personalizado de forma permanente.

Método 3: plugins de seguridad

Si no quiere tocar código, instale un plugin. Tres opciones probadas:

• Wordfence Security. El firewall para WordPress más popular. Además de bloquear XML-RPC, proporciona un escáner de malware, protección de inicio de sesión y monitoreo de tráfico. En ajustes de Wordfence → Seguridad de inicio de sesión → marque «Deshabilitar autenticación XML-RPC».

• Disable XML-RPC-API. Un plugin ligero que hace exactamente una cosa: engancha el filtro xmlrpc_enabled y deshabilita el endpoint. Sin ajustes adicionales; active y olvídese.

• iThemes Security (Solid Security). Un plugin integral con un módulo de Ajustes de WordPress donde XML-RPC se deshabilita con una sola casilla de verificación. También cierra otros vectores: cambios de prefijo de tabla, deshabilitar el editor de archivos desde el admin, protección de fuerza bruta.

Después de activar cualquiera de estos plugins, verifique siempre que xmlrpc.php devuelva un error, no un saludo.

Método 4: bloqueo a nivel de firewall (Cloudflare / Sucuri)

El nivel de protección más potente es un firewall web que descarta las solicitudes maliciosas antes de que lleguen a su hosting.

WAF de Cloudflare. Cree una regla personalizada: el campo URI Path contiene xmlrpc.php → acción Bloquear. Las solicitudes se filtran a nivel de la red de Cloudflare (más de 330 puntos de presencia en todo el mundo); su servidor nunca las ve. El plan gratuito incluye 5 reglas personalizadas, lo cual es suficiente. Extra: Cloudflare muestra estadísticas de solicitudes bloqueadas, y puede ver la escala del ataque con sus propios ojos.

Sucuri Website Firewall. Enfoque similar: una regla WAF en la URI /xmlrpc.php. Sucuri también ofrece monitoreo de integridad de archivos y limpieza automática de malware.

Una regla de firewall funciona bien combinada con .htaccess o la deshabilitación programática: el firewall corta la basura masiva, mientras que el bloqueo local sirve como respaldo en caso de que el tráfico de alguna manera eluda el WAF.

Qué hacer si usa Jetpack

Jetpack de Automattic usa XML-RPC para vincular su sitio con los servidores de WordPress.com. Si deshabilita completamente xmlrpc.php, Jetpack deja de funcionar: estadísticas, suscripciones, CDN de imágenes, el módulo de Publicaciones relacionadas y la protección de fuerza bruta de Jetpack se rompen a la vez.

La solución: no elimine XML-RPC por completo, sino permita selectivamente las solicitudes de los servidores de Jetpack:

• Deje xmlrpc.php accesible (NO bloquee mediante .htaccess y NO enganche el filtro xmlrpc_enabled).

• Configure el WAF de Cloudflare así: permita solicitudes a xmlrpc.php SOLO desde los rangos de IP de Automattic (la lista se actualiza en la documentación de Jetpack), bloquee el resto.

• Como mínimo, elimine los encabezados RSD y WLW usando el fragmento del método 2, para no exponer el endpoint en <head> innecesariamente.

• Instale Wordfence y habilite la protección de fuerza bruta específicamente para xmlrpc.php; no bloquea las solicitudes legítimas de Jetpack pero corta los intentos de adivinanza de contraseñas.

⁉️🤔 Preguntas frecuentes

¿Puedo simplemente eliminar el archivo xmlrpc.php del servidor?

Puede, pero es una mala práctica. En la próxima actualización de WordPress, el archivo se restaurará y usted volverá a ser vulnerable. Es mejor bloquear el acceso mediante .htaccess o deshabilitar la funcionalidad con un filtro en código: el efecto es el mismo, pero las actualizaciones del núcleo no romperán su protección. Si eliminó el archivo, asegúrese de eliminar rsd_link de wp_head, de lo contrario los visitantes obtendrán un 404 al seguir el enlace EditURI.

¿Deshabilitar XML-RPC romperá WooCommerce?

No. WooCommerce ha hecho la transición completa a la API REST de WordPress y no depende de XML-RPC. Su tienda seguirá funcionando sin cambios. La única excepción es si utiliza una solución personalizada antigua vinculada a XML-RPC, pero prácticamente no queda ninguna.

¿Qué pasa si mi proveedor de hosting ya bloquea xmlrpc.php?

Si el proveedor ya ha deshabilitado XML-RPC a nivel de servidor, no necesita hacer nada; el endpoint es inaccesible. Verifique: abra xmlrpc.php; si ve 403, la protección está funcionando. Lo único que vale la pena agregar es eliminar los encabezados RSD y WLW mediante functions.php, porque el proveedor no los toca.

¿Necesito deshabilitar XML-RPC si estoy en hosting WordPress gestionado?

La mayoría de los hosts gestionados (Kinsta, WP Engine, SiteGround) bloquean o limitan estrictamente xmlrpc.php a nivel de plataforma. Verifique si el endpoint está abierto mediante el navegador. Si está bloqueado, no se requiere acción adicional. Si está abierto, agregue la regla .htaccess: los hosts gestionados no la sobrescriben.

¿Cómo sé si mi sitio está siendo atacado a través de xmlrpc.php ahora mismo?

Tres señales: un pico agudo en la carga del servidor con tráfico sin cambios, cientos de solicitudes POST idénticas a xmlrpc.php en los registros de acceso y errores de límite de memoria/CPU de su proveedor de hosting. Active el monitoreo (Wordfence → Tráfico en vivo o Cloudflare → Eventos de seguridad); verá la fuente y la escala del ataque en tiempo real.

Vale la pena deshabilitar xmlrpc.php en 2026

Respuesta corta: sí, si no usa Jetpack y no publica entradas a través de la aplicación móvil de WordPress.

XML-RPC es un legado de la era de WordPress 1.5. La API REST ha ocupado su lugar hace tiempo, y xmlrpc.php se ha convertido en una puerta abierta para ataques de fuerza bruta y DDoS. Cerrarla lleva cinco minutos. Elija el método para su situación:

• No quiere tocar código: instale Disable XML-RPC-API, dos clics.
• Tiene acceso a los archivos del servidor: agregue una regla a .htaccess, el nivel de servidor es más fiable.
• Prefiere código limpio: aplique el filtro xmlrpc_enabled y elimine los encabezados con dos fragmentos en functions.php.
• Quiere la máxima protección: configure una regla WAF en Cloudflare y combínela con un bloqueo local.

Después de bloquear, verifique siempre que xmlrpc.php devuelva 403 Forbidden y monitorice los registros durante al menos una semana; se sorprenderá de cuánto tráfico basura desaparece. Suscríbase también a las actualizaciones de WordPress: la historia muestra que los protocolos antiguos mueren lentamente, y pueden surgir nuevas vulnerabilidades XML-RPC incluso después de 2026.