Para bloquear xmlrpc.php en WordPress, agrega una regla en tu archivo .htaccess que deniegue todas las peticiones a ese archivo — es el método más efectivo, inmediato y sin dependencias de plugins.
El archivo xmlrpc.php es una interfaz heredada de WordPress diseñada para que aplicaciones externas (como apps móviles antiguas y Jetpack) se comuniquen con el sitio. Hoy en día la API REST de WordPress cumple esa función y, en la mayoría de los sitios, xmlrpc solo sirve como puerta de entrada para atacantes. A continuación, te explicamos por qué es peligroso y cómo cerrarlo.
¿Por qué xmlrpc.php es un riesgo de seguridad?
Los atacantes explotan xmlrpc.php de tres formas principales:
- Fuerza bruta amplificada: El método
system.multicallpermite probar cientos de combinaciones de usuario/contraseña en una sola petición HTTP, evadiendo límites de intentos que solo cuentan peticiones individuales. - DDoS por amplificación: El servidor responde con payloads mucho más grandes que la petición, convirtiéndolo en punto de amplificación.
- Pingback para escaneo de IPs internas: La función de pingback puede usarse para detectar servicios internos en la red del servidor.
Según estadísticas de firewalls WAF, xmlrpc.php recibe entre el 10 % y el 30 % de todo el tráfico malicioso dirigido a instalaciones WordPress. En la mayoría de los sitios actuales, bloquearlo no rompe ninguna funcionalidad.
Método 1: Bloquear xmlrpc.php con .htaccess (Apache)
Este es el método recomendado para servidores Apache, que incluye la mayoría del hosting compartido y cPanel.
Abre el archivo .htaccess en la raíz de tu WordPress y agrega estas líneas antes del bloque de WordPress:
# Bloquear acceso a xmlrpc.php
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>
Guarda el archivo. El servidor devolverá un error 403 Forbidden a cualquier petición a xmlrpc.php, sin procesar ninguna lógica PHP.
Alternativa con mod_rewrite
# Alternativa con RewriteRule
RewriteRule ^xmlrpc\.php$ - [F,L]
Ambas opciones son equivalentes en efectividad. La directiva <Files> es ligeramente más eficiente porque actúa a nivel de configuración de Apache, antes de que mod_rewrite entre en juego.
Método 2: Bloquear xmlrpc.php en Nginx
Si tu servidor usa Nginx, agrega este bloque dentro del contexto server de tu sitio:
location = /xmlrpc.php {
deny all;
return 403;
}
Recarga la configuración de Nginx con sudo nginx -s reload o el equivalente en tu panel de administración.
Método 3: Bloquear xmlrpc.php con un plugin de WordPress
Si no tienes acceso a los archivos del servidor o prefieres una solución sin tocar código, puedes usar un plugin:
- Disable XML-RPC: Plugin ligero y de un solo propósito. Instala, activa y listo — sin configuración adicional.
- Wordfence Security: Desde su panel, ve a Firewall → Bloquear y añade una regla para
xmlrpc.php. También ofrece bloqueo por países y límite de intentos de login. - iThemes Security / Solid Security: Incluye la opción "Disable XML-RPC" en su sección de Hardening.
El inconveniente de los plugins es que la regla de bloqueo se aplica después de que PHP carga WordPress — menos eficiente que el bloqueo a nivel de servidor.
¿Cómo verificar que xmlrpc.php está bloqueado?
Comprueba el bloqueo con curl desde una terminal:
curl -s -o /dev/null -w "%{http_code}" https://tudominio.com/xmlrpc.php
Deberías recibir un 403. Si recibes un 200 o un XML de respuesta, el bloqueo no está activo.
También puedes usar herramientas en línea como xmlrpc.defense.cc o simplemente intentar acceder al archivo desde el navegador — un 403 confirma que está protegido.
¿Qué pasa si necesito xmlrpc.php para algo?
Los casos en que xmlrpc.php sigue siendo necesario son cada vez más raros:
- Jetpack: Las versiones modernas de Jetpack usan la API REST de WordPress. Si usas una versión antigua, actualiza antes de bloquear xmlrpc.
- Apps de escritorio antiguas (como Windows Live Writer): Considera migrar a una herramienta moderna compatible con la API REST.
- Integración con terceros legacy: Consulta con el proveedor del servicio si hay una alternativa basada en API REST.
Si necesitas mantener xmlrpc activo solo para una IP específica (por ejemplo, la IP de tu app), usa esta variante en .htaccess:
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
Allow from 203.0.113.10
</Files>
Para una estrategia de seguridad WordPress completa — bloqueo de xmlrpc, hardening de cabeceras y auditoría de plugins — puedes contar con el equipo de elenlace.com, especialistas en seguridad web para negocios en México.
Conclusiones clave
- xmlrpc.php es un vector de ataque activamente explotado en WordPress para fuerza bruta, DDoS y escaneo de red.
- El método más eficiente es bloquearlo a nivel de servidor: con
<Files>en Apache o con un bloquelocationen Nginx. - La mayoría de sitios WordPress modernos no necesitan xmlrpc.php — la API REST cubre todas sus funciones.
- Verifica el bloqueo con
curlo desde el navegador: el servidor debe devolver un 403. - Si algún servicio lo requiere, restringe el acceso a IPs específicas en lugar de dejarlo abierto a todos.
Bloquear xmlrpc.php es solo uno de los pasos del endurecimiento de WordPress. Para una revisión completa de la seguridad de tu sitio, visita elenlace.com y solicita una auditoría.
Preguntas frecuentes
¿Bloquear xmlrpc.php rompe el login de WordPress?
No. El inicio de sesión normal de WordPress usa /wp-login.php, no xmlrpc.php. Bloquear xmlrpc no afecta el acceso al panel de administración ni a ninguna función del front-end.
¿WordPress 6.x todavía incluye xmlrpc.php?
Sí. A pesar de que la API REST reemplazó sus funciones, el archivo sigue incluido en WordPress por compatibilidad con versiones antiguas. No desaparecerá pronto, por lo que bloquearlo manualmente sigue siendo necesario.
¿Es suficiente deshabilitar xmlrpc desde el panel de WordPress?
WordPress no tiene una opción nativa para deshabilitar xmlrpc desde el panel de administración. La única forma de hacerlo sin plugins es a nivel de servidor (.htaccess o Nginx). Los plugins de seguridad añaden esa opción, pero con mayor costo en rendimiento que el bloqueo en servidor.
¿Qué diferencia hay entre bloquear xmlrpc.php y deshabilitarlo con un filtro PHP?
El filtro PHP (add_filter('xmlrpc_enabled', '__return_false')) deshabilita la funcionalidad pero WordPress sigue cargando el archivo completo ante cada petición. El bloqueo en servidor (Apache/Nginx) rechaza la petición antes de que PHP se ejecute, lo que además reduce la carga del servidor significativamente.
Para saber más
Otros proveedores y guías que vale la pena comparar:
