Cómo habilitar y deshabilitar xmlrpc.php en WordPress (y por qué es importante)

El archivo xmlrpc.php es un componente central de WordPress que expone un endpoint de API XML-RPC, permitiendo que aplicaciones remotas se autentiquen y ejecuten operaciones del lado del servidor — publicar entradas, gestionar comentarios, activar pingbacks y más. Dado que acepta solicitudes POST no autenticadas de forma predeterminada y las procesa antes de que la mayoría de las capas de seguridad se activen, es una de las superficies de ataque más frecuentemente abusadas en cualquier instalación de WordPress.

Si no utilizas la aplicación móvil de WordPress, Jetpack, ni ningún servicio de terceros que requiera explícitamente XML-RPC, deshabilitar xmlrpc.php es la postura de seguridad predeterminada correcta. Si dependes de esas integraciones, puedes reforzar el endpoint en lugar de eliminarlo por completo.

Qué es xmlrpc.php y cómo funciona

XML-RPC (Llamada a Procedimiento Remoto en Lenguaje de Marcado Extensible) es un protocolo que codifica llamadas a funciones en XML y las transmite a través de HTTP. WordPress incluye un servidor XML-RPC completo desde la versión 3.5, implementado en el archivo xmlrpc.php ubicado en el directorio raíz de WordPress.

Cuando un cliente remoto — una aplicación móvil, un cliente de blogging de escritorio o un script de automatización — envía una solicitud POST a https://yourdomain.com/xmlrpc.php, WordPress analiza el payload XML, autentica las credenciales incluidas en el cuerpo de la solicitud y ejecuta el método solicitado. Todo el intercambio ocurre en un único viaje de ida y vuelta HTTP, lo cual es tanto su fortaleza como su debilidad fundamental desde el punto de vista de la seguridad.

Métodos XML-RPC principales expuestos por WordPress

• wp.newPost / wp.editPost — crear y actualizar entradas de forma remota
• wp.getComments / wp.deleteComment — gestionar comentarios
• wp.uploadFile — subir archivos multimedia al servidor
• pingback.ping — notificar a un sitio remoto que ha sido enlazado
• system.multicall — agrupar múltiples llamadas a métodos en una sola solicitud HTTP

El método system.multicall es particularmente peligroso. Una sola solicitud HTTP puede agrupar cientos de llamadas wp.getUsersBlogs, cada una probando una contraseña diferente. Esto permite a un atacante realizar miles de intentos de autenticación generando solo una entrada en el registro del servidor, eludiendo las herramientas de limitación de velocidad que cuentan solicitudes individuales.

Riesgos de seguridad de dejar xmlrpc.php habilitado

Amplificación de fuerza bruta mediante system.multicall

Los ataques de fuerza bruta tradicionales envían un par de credenciales por solicitud HTTP. Con XML-RPC, un atacante agrupa 500 intentos de inicio de sesión dentro de un único payload system.multicall. Una regla estándar de fail2ban o un contador de intentos de inicio de sesión ve una sola solicitud; el atacante obtiene 500 intentos. Este no es un riesgo teórico — es el exploit de XML-RPC más común observado en la práctica.

DDoS amplificado mediante pingback

WordPress procesa automáticamente las solicitudes de pingback entrantes a través de xmlrpc.php. Un atacante puede enviar una solicitud pingback.ping manipulada a miles de sitios WordPress, instruyendo a cada uno para que envíe una solicitud HTTP a una única URL víctima. La víctima recibe una avalancha volumétrica de solicitudes provenientes de servidores WordPress legítimos, haciendo que el bloqueo basado en IP sea ineficaz. Tu servidor se convierte simultáneamente en víctima (agotamiento de recursos) y en un amplificador de ataques involuntario.

SSRF mediante pingback

El mecanismo de pingback puede ser abusado para realizar Server-Side Request Forgery (SSRF). Un atacante envía una solicitud pingback.ping donde la URL de origen apunta a un recurso de red interno — http://192.168.1.1/admin, por ejemplo. El servidor WordPress obtiene esa URL desde dentro del perímetro de red, potencialmente exponiendo servicios internos que no son enrutables públicamente.

Exposición de credenciales en tránsito

XML-RPC transmite las credenciales en el cuerpo del POST como texto plano dentro del sobre XML. Si tu sitio no aplica HTTPS, las credenciales quedan expuestas a cualquier observador de red. Incluso con TLS, las credenciales están incluidas en cada solicitud — no existe token de sesión ni flujo OAuth para limitar la ventana de exposición.

Cuándo deberías mantener xmlrpc.php habilitado

Deshabilitarlo de forma predeterminada, pero mantenlo habilitado si tu flujo de trabajo depende genuinamente de alguno de los siguientes:

• Aplicación móvil de WordPress (iOS/Android): La aplicación oficial utiliza XML-RPC para todas las operaciones de gestión del sitio en instalaciones de WordPress autoalojadas.
• Plugin Jetpack: Varios módulos de Jetpack — incluyendo publicize, notificaciones push móviles y algunas funciones de estadísticas — se comunican mediante XML-RPC con los servidores de WordPress.com.
• Clientes de blogging de escritorio: MarsEdit, Windows Live Writer y herramientas similares dependen exclusivamente de la API XML-RPC.
• Pipelines de publicación automatizada: IFTTT, Zapier y scripts personalizados que envían contenido a WordPress frecuentemente usan XML-RPC cuando la API REST no está configurada.
• Pingbacks/trackbacks entre sitios WordPress: Si las notificaciones de pingback entre sitios forman parte de tu flujo de trabajo editorial, deshabilitar xmlrpc.php las silenciará.

Si ninguno de estos casos aplica, no hay razón operativa para dejar el endpoint abierto.

xmlrpc.php vs. la API REST de WordPress

WordPress introdujo la API REST en la versión 4.7 como un reemplazo moderno basado en tokens para XML-RPC. Comprender las diferencias te ayuda a decidir si deshabilitar XML-RPC rompe algo crítico.

Si estás construyendo una nueva integración o migrando una existente, utiliza la API REST. El modelo de autenticación es significativamente más seguro, y el endpoint es mucho más fácil de auditar y limitar en velocidad a nivel de infraestructura.

Cómo deshabilitar xmlrpc.php en WordPress

Elige el método que se adapte a tu nivel de acceso al servidor y tolerancia al riesgo. Los métodos están ordenados de menor a mayor aplicación a nivel de servidor.

Método 1: Deshabilitar mediante plugin (más rápido, sin acceso al servidor requerido)

Para entornos de hosting compartido o sitios donde prefieres no editar archivos de configuración del servidor, un plugin es la opción más accesible.

Plugins recomendados:

• Disable XML-RPC-API — de propósito único, huella mínima, se activa instantáneamente
• All In One WP Security and Firewall — suite de seguridad más amplia con controles granulares de XML-RPC

Pasos para Disable XML-RPC-API:

1. Ve a Plugins > Añadir nuevo en tu panel de WordPress.
2. Busca “Disable XML-RPC-API” y haz clic en Instalar ahora, luego en Activar.
3. No se requiere configuración adicional — el plugin se engancha a xmlrpc_enabled y devuelve false inmediatamente al activarse.

Pasos para All In One WP Security and Firewall:

1. Después de activar el plugin, ve a WP Security > Firewall.
2. Localiza la sección XML-RPC.
3. Habilita la opción para bloquear completamente las solicitudes XML-RPC.
4. Guarda la configuración.

Limitación: El bloqueo basado en plugin se ejecuta dentro del contexto de ejecución PHP de WordPress. El servidor aún inicia PHP, carga WordPress y procesa la solicitud antes de rechazarla. Bajo un ataque intenso, esto consume CPU y memoria. Para sitios de alto tráfico bajo ataque activo, utiliza el método .htaccess o Nginx en su lugar.

Método 2: Deshabilitar mediante .htaccess (Apache — bloqueo a nivel de servidor)

Bloquear en el nivel .htaccess evita que PHP se ejecute en absoluto para las solicitudes dirigidas a xmlrpc.php. Esto es significativamente más eficiente bajo carga.

1. Conéctate a tu servidor mediante FTP, SFTP o el administrador de archivos de tu hosting y abre el archivo .htaccess en tu directorio raíz de WordPress (normalmente public_html/.htaccess).
2. Añade el siguiente bloque. Colócalo antes de las reglas de reescritura estándar de WordPress:

# Block all access to xmlrpc.php
<Files "xmlrpc.php">
    Order Deny,Allow
    Deny from all
</Files>

1. Guarda el archivo.

Para verificar que el bloqueo está activo, ejecuta una prueba desde tu máquina local:

curl -s -o /dev/null -w "%{http_code}" -X POST https://yourdomain.com/xmlrpc.php

Deberías recibir una respuesta 403. Un 200 o 405 significa que el bloqueo aún no está en vigor.

Caso especial — si aún necesitas pingbacks desde IPs de confianza específicas, puedes incluirlas en la lista blanca:

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

Método 3: Deshabilitar mediante configuración de Nginx

Si tu servidor ejecuta Nginx (común en entornos de Hosting VPS), los archivos .htaccess no tienen efecto. Añade el bloque directamente a la configuración del bloque de servidor de tu sitio.

# Block xmlrpc.php at the Nginx level
location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
    return 444;
}

La directiva return 444 cierra la conexión TCP sin enviar una respuesta HTTP, lo cual es más eficiente que un 403 porque evita que el cliente del atacante reciba cualquier retroalimentación. Después de editar, recarga Nginx:

sudo nginx -t && sudo systemctl reload nginx

Coloca este bloque location dentro de tu bloque server {}, antes de cualquier directiva try_files o de procesamiento PHP.

Método 4: Deshabilitar mediante functions.php (filtro hook de WordPress)

Este método utiliza un filtro de WordPress para deshabilitar XML-RPC en la capa de aplicación. Es menos eficiente que el bloqueo a nivel de servidor, pero útil cuando no tienes acceso directo al servidor y deseas una solución basada en código sin dependencia de un plugin.

1. Ve a Apariencia > Editor de temas en tu panel de WordPress, o accede al archivo directamente mediante SFTP en wp-content/themes/your-theme/functions.php.
2. Añade lo siguiente al final del archivo:

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

1. Guarda el archivo.

Advertencia importante: Este filtro deshabilita los métodos XML-RPC autenticados, pero no bloquea el método pingback.ping ni impide que se acceda al archivo. El servidor aún procesa la solicitud hasta el punto en que WordPress evalúa el filtro. Para una protección completa, combina esto con el bloqueo .htaccess o Nginx.

Si estás usando un tema hijo, siempre añade el código personalizado al functions.php del tema hijo, no al tema padre. Las actualizaciones del tema padre sobrescribirán tus cambios.

Método 5: Deshabilitación selectiva — bloquear solo los pingbacks

Si necesitas XML-RPC para Jetpack o publicación móvil pero deseas eliminar el vector de amplificación DDoS, puedes deshabilitar solo el método de pingback manteniendo el resto de la API funcional.

// Disable only the pingback method, keep XML-RPC otherwise functional
add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['pingback.ping'] );
    unset( $methods['pingback.extensions.getPingbacks'] );
    return $methods;
} );

Añade esto al functions.php de tu tema hijo o a un plugin específico del sitio. Esta es la configuración recomendada para sitios que ejecutan Jetpack pero no necesitan recibir pingbacks.

Cómo volver a habilitar xmlrpc.php

Revertir cualquiera de los métodos anteriores restaura el acceso a XML-RPC:

• Método de plugin: Desactiva o elimina el plugin de bloqueo desde Plugins > Plugins instalados.
• Método .htaccess: Elimina el bloque <Files "xmlrpc.php"> de .htaccess y guarda.
• Método Nginx: Elimina el bloque location = /xmlrpc.php de la configuración de tu servidor y recarga Nginx con sudo systemctl reload nginx.
• Método functions.php: Elimina la línea add_filter( 'xmlrpc_enabled', '__return_false' ) y guarda.

Después de volver a habilitar, verifica que el endpoint responde correctamente:

curl -s -X POST https://yourdomain.com/xmlrpc.php 
  -H "Content-Type: text/xml" 
  --data '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName><params></params></methodCall>'

Una respuesta XML válida que liste los métodos disponibles confirma que el endpoint está activo.

Reforzar xmlrpc.php sin deshabilitarlo

Si deshabilitar no es una opción, aplica estas mitigaciones para reducir la superficie de ataque:

Aplicar HTTPS: Asegúrate de que tu sitio utilice un certificado TLS válido. Si aún no lo has hecho, configura uno a través de tu proveedor de hosting — los Certificados SSL previenen la interceptación de credenciales en tránsito.

Limitar la velocidad a nivel de firewall o CDN: Configura tu WAF (Cloudflare, ModSecurity) para limitar las solicitudes POST a xmlrpc.php a un máximo de 5–10 por minuto por IP.

Bloquear system.multicall específicamente:

add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['system.multicall'] );
    return $methods;
} );

Esto elimina el vector de amplificación de fuerza bruta mientras preserva toda la demás funcionalidad XML-RPC.

Restringir por IP: Si solo accedes a XML-RPC desde direcciones IP conocidas (el rango de IP del operador de tu aplicación móvil, o una IP de oficina estática), incluye esas direcciones en la lista blanca en .htaccess o Nginx y deniega todas las demás.

Monitorear los registros de acceso: Audita regularmente los registros de tu servidor en busca de solicitudes POST repetidas a xmlrpc.php. Un pico en solicitudes POST con estado 200 a este archivo es un indicador confiable de una campaña de fuerza bruta en curso.

En un VPS con cPanel u otro entorno de panel administrado, puedes configurar reglas de ModSecurity directamente desde el panel de control para aplicar estas restricciones sin necesidad de editar archivos manualmente.

Elegir el método correcto: matriz de decisión

Para sitios en producción alojados en Servidores Dedicados, el bloqueo a nivel de servidor Nginx o Apache siempre es preferible a una solución basada en plugin, ya que evita la ejecución de PHP por completo para las solicitudes maliciosas, eliminando la sobrecarga de CPU que el bloqueo basado en plugin genera bajo ataques sostenidos.

Lista de verificación práctica de puntos clave

• Audita si algún plugin o servicio activo en tu stack realmente requiere XML-RPC antes de deshabilitarlo — verifica Jetpack, aplicaciones móviles y cualquier herramienta de automatización de publicación.
• Si no existe ninguna dependencia, aplica el bloqueo a nivel de servidor (.htaccess o Nginx) en lugar de un plugin — es más eficiente y sobrevive a la desactivación de plugins.
• Si debes mantener XML-RPC activo, elimina incondicionalmente system.multicall y pingback.ping mediante el filtro xmlrpc_methods — estos dos métodos representan la gran mayoría del abuso de XML-RPC.
• Siempre aplica HTTPS en cualquier sitio WordPress que acepte solicitudes autenticadas, incluyendo XML-RPC.
• Después de aplicar cualquier bloqueo, verifica con curl que el endpoint devuelve 403 o cierra la conexión — no asumas que la configuración es correcta sin realizar pruebas.
• En entornos VPS o servidores dedicados basados en Nginx, usa return 444 en lugar de deny all para evitar dar a los atacantes cualquier retroalimentación a nivel HTTP.
• Registra y monitorea las solicitudes POST a xmlrpc.php — un pico repentino es una advertencia temprana de una campaña de relleno de credenciales o amplificación DDoS.
• Si administras múltiples sitios WordPress, considera centralizar esta configuración a nivel de servidor o CDN en lugar de aplicar reglas de plugin por sitio.

Para sitios que necesitan gestión remota robusta sin la superficie de riesgo de XML-RPC, migrar las integraciones a la API REST de WordPress con contraseñas de aplicación es el camino correcto a largo plazo. La API REST proporciona revocación por token, permisos con alcance definido y semántica HTTP estándar que son mucho más fáciles de asegurar y auditar.

Si estás configurando un nuevo entorno WordPress y deseas una base limpia y segura desde el principio, los Paneles de Control VPS con ModSecurity preconfigurado te ofrecen protección WAF a nivel de servidor sin necesidad de crear reglas manualmente.

—

Preguntas frecuentes

¿Deshabilitar xmlrpc.php rompe la API REST de WordPress?

No. La API REST (/wp-json/) es un endpoint completamente separado con su propia autenticación y enrutamiento. Bloquear xmlrpc.php no tiene ningún efecto sobre la funcionalidad de la API REST. Los dos sistemas son arquitectónicamente independientes.

¿Deshabilitar xmlrpc.php romperá Jetpack?

Depende de qué módulos de Jetpack utilices. Jetpack ha migrado progresivamente las funciones a la API REST, pero algunos módulos más antiguos — incluyendo ciertas funciones de publicize y notificaciones — aún se comunican mediante XML-RPC. Consulta la página de depuración de Jetpack en Jetpack > Panel > Depurar para ver si la conectividad XML-RPC aparece como un requisito antes de deshabilitarlo.

¿Es más seguro el método .htaccess o el método functions.php?

El método .htaccess es significativamente más seguro bajo condiciones de ataque. Bloquea la solicitud en la capa del servidor web antes de que PHP se cargue, consumiendo recursos mínimos. El filtro functions.php se ejecuta dentro del contexto de ejecución PHP de WordPress, lo que significa que el servidor aún arranca WordPress para cada solicitud bloqueada — lo cual es costoso bajo un ataque de alto volumen.

¿Puede un atacante seguir explotando xmlrpc.php si solo lo deshabilito mediante el filtro de WordPress?

Parcialmente. El filtro xmlrpc_enabled previene las llamadas a métodos autenticados, pero el archivo permanece accesible públicamente y el servidor aún procesa las solicitudes entrantes. El endpoint de pingback puede permanecer parcialmente funcional dependiendo de la versión de WordPress. Para una protección completa, combina el filtro con un bloqueo a nivel de servidor.

¿Cómo verifico si xmlrpc.php está actualmente accesible en mi sitio?

Ejecuta el siguiente comando desde tu terminal local, reemplazando el dominio con el tuyo:

curl -s -o /dev/null -w "%{http_code}" -X POST https://yourdomain.com/xmlrpc.php

Una respuesta 200 significa que el endpoint está abierto. Un 403 o una caída de la conexión (000) confirma que está bloqueado. También puedes usar la herramienta en línea en xmlrpc.eritreo.it para probar específicamente la vulnerabilidad de pingback.