Cada sitio WordPress almacena un archivo «silencioso» en la raíz que la mayoría de los propietarios descubren solo después de un ataque. Su nombre es xmlrpc.php. El archivo en sí no es malicioso: WordPress advierte honestamente que es una interfaz para interacción remota. Pero es a través de este archivo que los bots llevan años forzando contraseñas por fuerza bruta, enviando pingbacks de spam y generando tráfico DDoS.

Según datos de Wordfence para 2024, los ataques a través de XML-RPC están entre los cinco principales vectores de ataque contra sitios WordPress. Una sola solicitud system.multicall permite a un atacante probar cientos de contraseñas a la vez, en lugar de una como a través del formulario de inicio de sesión. Los proveedores de alojamiento registran millones de estos intentos al mes en un sitio promedio.

Entendamos por qué este archivo es necesario, quién debería conservarlo y, lo más importante, mostremos cinco formas de deshabilitar o bloquear de forma segura xmlrpc.php, desde un plugin de un clic hasta ediciones específicas de .htaccess.

💡 Resumen rápido:

• Conozca qué es xmlrpc.php y qué funciones de WordPress dependen de él (pingback, aplicación móvil, Jetpack)
• Evalúe los riesgos reales: amplificación de fuerza bruta, DDoS por pingback y escaneo de directorios por bots
• Elija el método de protección adecuado: deshabilitar mediante plugin, bloquear a través de .htaccess, cerrar el acceso a nivel de servidor web o eliminar el archivo
• Configure la monitorización: cómo asegurarse de que xmlrpc.php ya no responde a solicitudes

Qué es xmlrpc.php y qué funciones de WordPress dependen de él

XML-RPC es un protocolo de llamada a procedimiento remoto que funciona sobre HTTP y transmite datos en formato XML. La tecnología apareció a finales de los años 90, mucho antes de la API REST, y WordPress la heredó en sus primeros días. El archivo xmlrpc.php en la raíz del sitio acepta solicitudes XML, las procesa y devuelve una respuesta, por ejemplo, publica una entrada, sube un archivo multimedia o verifica los permisos de usuario.

En la práctica, varios escenarios funcionan a través de xmlrpc.php:

• Pingbacks y trackbacks. Cuando alguien enlaza a su entrada, su sitio envía una solicitud XML-RPC con una notificación. Su WordPress verifica el enlace y, si es real, añade el pingback a los comentarios.

• Publicación remota. Aplicaciones como el antiguo Windows Live Writer o clientes de escritorio (TextMate, MarsEdit) usaban XML-RPC para escribir y enviar entradas sin entrar al panel de administración.

• Aplicación móvil de WordPress. La aplicación oficial para iOS y Android dependió de XML-RPC durante mucho tiempo, aunque ahora está migrando cada vez más a la API REST.

• Integraciones. Servicios como Jetpack (parte de su funcionalidad), IFTTT y algunas herramientas SEO aún usan XML-RPC para conectarse al sitio.

Con el lanzamiento de la API REST de WordPress en la versión 4.7 (diciembre de 2016), la mayoría de las integraciones modernas migraron al nuevo protocolo. La API REST es más rápida, trabaja con JSON en lugar de XML y está mejor documentada. No obstante, WordPress aún incluye xmlrpc.php en cada instalación por compatibilidad con versiones anteriores.

Matiz importante: a partir de WordPress 2.6 (allá por 2008), la funcionalidad de publicación remota mediante XML-RPC está deshabilitada por defecto. Para habilitarla, necesita marcar explícitamente la casilla en «Ajustes → Escritura». Los pingbacks y trackbacks continúan funcionando al mismo tiempo.

Cómo es peligroso xmlrpc.php: tres vectores de ataque principales

Los desarrolladores de WordPress han parcheado xmlrpc.php más de una vez. En la versión 2.1.2, un usuario autenticado con derechos de «colaborador» podía publicar una entrada saltándose las restricciones. En la 2.3.1, descubrieron una fuga de información a través de XML-RPC. Ambos agujeros se cerraron rápidamente, pero el protocolo en sí permaneció arquitectónicamente vulnerable a tres clases de ataques que siguen siendo relevantes en 2026.

Amplificación de fuerza bruta mediante system.multicall

El principal problema es el método system.multicall. Permite empaquetar múltiples llamadas wp.getUsersBlogs en una sola solicitud HTTP. Cada llamada verifica un par «usuario + contraseña». Así, en lugar de un intento por solicitud, el atacante hace cientos. Cloudflare ha registrado picos de decenas de miles de estas solicitudes por hora en un solo sitio.

El formulario de inicio de sesión normal wp-login.php está limitado a un inicio de sesión por intento y se protege fácilmente con un plugin como Wordfence o Limit Login Attempts. xmlrpc.php elude todos estos limitadores porque funciona a través de un endpoint diferente.

DDoS por pingback

La función de pingback está diseñada como una notificación inofensiva. Pero un atacante puede enviar solicitudes de pingback falsas en nombre de cientos de sitios, y su servidor irá a verificar cada «enlace», cargando la CPU, la red y la base de datos. Con suficiente escala, el sitio se cae. Sucuri en su informe de 2023 califica los ataques de pingback como uno de los vectores DDoS más comunes contra WordPress.

Escaneo de directorios por bots

Los bots buscan xmlrpc.php no solo en la raíz, sino también en subdirectorios inventados como /2026/01/xmlrpc.php y /blog/xmlrpc.php. Cada una de estas solicitudes devuelve un 404 y desperdicia recursos del servidor. Incluso si el ataque falló, decenas de miles de solicitudes basura ralentizan el sitio y saturan los registros. En la práctica, los propietarios ven cómo las gráficas en cPanel entran en zona roja, y la razón son precisamente los bots escaneando xmlrpc.php.

5 Formas de deshabilitar o asegurar xmlrpc.php

A continuación se presentan cinco métodos, del más simple al más radical. Elija según su situación: si usa la aplicación móvil, si necesita pingbacks, qué alojamiento tiene.

1. Deshabilitar mediante plugin

La vía más segura para quienes no quieren tocar el código. Instale un plugin y bloqueará el acceso a xmlrpc.php a nivel de WordPress, antes de que comience el procesamiento de la solicitud.

Ventajas: no necesita editar .htaccess ni functions.php, fácil de reactivar. Desventajas: añade otro plugin al panel de administración, la protección se elimina al desactivarlo.

Un par de opciones probadas:

• Disable XML-RPC, minimalista, una acción: se activa y el acceso queda cerrado. Sin ajustes.
• Wordfence Security, firewall integral en el que deshabilitar XML-RPC es solo una de las funciones. Adecuado si ya usa Wordfence o planea instalarlo.

2. Bloquear mediante.htaccess

Si trabaja en un servidor Apache, el archivo .htaccess en la raíz del sitio le permite bloquear el acceso antes de que la solicitud llegue a WordPress. Esto reduce la carga: Apache devuelve 403 Forbidden inmediatamente, sin ejecutar PHP.

Añada el siguiente bloque a .htaccess al principio del archivo, antes de # BEGIN WordPress:

1
<IfModule mod_alias.c>
2
    RedirectMatch 403 /(.*)/xmlrpc.php$
3
</IfModule>

La directiva RedirectMatch 403 captura cualquier URL que termine en /xmlrpc.php, incluyendo subdirectorios como /2025/06/xmlrpc.php, y devuelve instantáneamente 403.

Ventajas: no toca el código de WordPress, funciona antes de que PHP se cargue, ahorra recursos. Desventajas: necesita editar .htaccess manualmente, al cambiar de alojamiento o tema el archivo puede sobrescribirse.

Importante: antes de editar .htaccess, haga una copia de seguridad. Un error en la sintaxis de .htaccess puede tumbar el sitio (500 Internal Server Error).

3. Eliminar enlaces mediante functions.php

Este método no bloquea el archivo en sí, sino que elimina los enlaces HTML a xmlrpc.php y wlwmanifest.xml de la sección <head> del sitio. El beneficio es una visibilidad reducida: los bots que analizan HTML no ven un puntero directo al endpoint XML-RPC.

Añada al functions.php del tema activo (o mediante el plugin Code Snippets):

1
remove_action('wp_head', 'rsd_link');
2
remove_action('wp_head', 'wlwmanifest_link');

El hook rsd_link genera <link rel="EditURI">, un enlace a xmlrpc.php para clientes Really Simple Discovery. El hook wlwmanifest_link es para Windows Live Writer (sin soporte desde hace tiempo, pero WordPress aún lo genera).

Ventajas: <head> limpio sin enlaces basura. Desventajas: xmlrpc.php permanece físicamente accesible mediante URL directa, esto no es bloqueo sino enmascaramiento.

4. Cerrar el acceso mediante WAF o Cloudflare

El Firewall de Aplicaciones Web bloquea las solicitudes a xmlrpc.php antes de que lleguen a su servidor. Este es el enfoque más efectivo para sitios en cualquier alojamiento.

Opciones de configuración:

• Cloudflare (plan gratuito): Regla WAF → Bloquear → El campo Ruta URI contiene /xmlrpc.php. La solicitud se rechaza a nivel de la red de Cloudflare, su servidor ni siquiera la ve.
• Wordfence WAF: Función integrada «Deshabilitar XML-RPC» en la sección del firewall.
• WAF del alojamiento: Kinsta, WP Engine y otros alojamientos gestionados le permiten deshabilitar XML-RPC en un par de clics a través del panel de control.

Ventajas: carga cero en el servidor, se puede ajustar con precisión (por ejemplo, permitir Jetpack mientras bloquea todo lo demás). Desventajas: requiere configuración del lado del WAF, no todos los proveedores de alojamiento ofrecen esta capacidad.

5. Eliminar o renombrar el archivo en sí

El método más radical. Usted elimina (o renombra) el archivo xmlrpc.php del servidor. Si el archivo no existe físicamente, no hay nada que procese las solicitudes, el servidor devuelve 404.

Matiz importante: en la próxima actualización de WordPress, el archivo se restaurará. Las actualizaciones automáticas del núcleo sobrescriben todos los archivos de WordPress, incluido xmlrpc.php. Por lo tanto, la eliminación es una medida temporal a menos que configure una limpieza periódica.

Si opta por esta vía, complemente la eliminación con la regla .htaccess del método 2. Sin ella, los bots seguirán llamando a la URL xmlrpc.php y el servidor devolverá honestamente 404 en cada solicitud, miles de errores en los registros.

¿Merece la pena deshabilitar xmlrpc.php?

La respuesta depende de lo que usted use. Repase la lista de verificación:

Si no usa una versión antigua de la aplicación móvil, no ha habilitado la gestión de Jetpack con WordPress.com y los pingbacks no son críticos para usted, deshabítelo sin dudar. En 2026, la API REST cubre casi todos los escenarios reales.

Vídeo: cómo deshabilitar XML-RPC en WordPress en 5 minutos

Vea una guía visual para deshabilitar xmlrpc.php, con demostración en pantalla y explicación de cada método:

⁉️🤔 Preguntas frecuentes

¿Es seguro simplemente ignorar xmlrpc.php?

En la mayoría de los casos, no. Incluso si no usa XML-RPC, los bots escanean este endpoint constantemente. Cada una de esas solicitudes carga el servidor. Es mejor cerrar explícitamente el acceso mediante .htaccess o plugin, esto elimina tanto el riesgo de fuerza bruta como las solicitudes basura en los registros.

¿Se romperá el sitio si se deshabilita xmlrpc.php?

WordPress en sí seguirá funcionando sin cambios. Solo verifique si está usando la gestión de Jetpack con WordPress.com o una versión antigua de la aplicación móvil. Si no es así, deshabítelo sin preocupación. Los pingbacks dejarán de llegar, pero la mayoría de los sitios ya no los usan para comunicación real de todos modos.

¿Cómo comprobar que xmlrpc.php está realmente bloqueado?

Abra en su navegador https://your-site.com/xmlrpc.php. Si ve una pantalla en blanco con el mensaje «XML-RPC server accepts POST requests only», el archivo está activo y respondiendo. Si obtiene 403 Forbidden o 404 Not Found, el bloqueo está funcionando. Para monitorización automática, puede usar verificadores en línea como xmlrpc.eror.xyz o una solicitud curl desde la consola.

¿Qué es mejor: plugin o.htaccess?

.htaccess bloquea la solicitud antes de que WordPress se inicie, esto ahorra recursos del servidor. Un plugin es más fácil de instalar y no requiere editar archivos. Para sitios no críticos casi no hay diferencia. Para proyectos de alta carga, es preferible .htaccess o una regla WAF.

¿Necesito actualizar WordPress después de deshabilitar xmlrpc.php?

No. Deshabilitar xmlrpc.php no depende de la versión de WordPress y no afecta a las actualizaciones del núcleo. El único matiz: si eliminó el archivo físicamente, la actualización lo restaurará, requiriendo eliminarlo de nuevo.

Entonces, ¿qué debería hacer con xmlrpc.php en su sitio?

No hay una respuesta universal, el contexto lo decide todo. Pero la práctica de miles de sitios WordPress da una imagen clara: si no sabe si necesita XML-RPC, no lo necesita.

¿Quiere fiabilidad sin meterse en código? Instale Disable XML-RPC. ¿Está dispuesto a dedicar cinco minutos al .htaccess? Obtenga protección a nivel de servidor sin plugins adicionales. ¿Usa Cloudflare? Configure una regla WAF y olvídese del problema.

Lo principal es no dejar xmlrpc.php abierto «por defecto». En 2026, cada endpoint de WordPress no cerrado es un objetivo para bots automatizados a los que no les importa si tiene un blog o una tienda en línea. Cierre el acceso usando uno de los métodos anteriores, verifique el resultado con una solicitud curl y duerma tranquilo.