Cómo Evitar Ataques a xmlrpc.php en WordPress (Guía Completa 2026)

📘 Este artículo forma parte de nuestra Guía Completa de Ciberseguridad 2026 y complementa nuestra Guía Completa de Servidores y Virtualización. Si quieres blindar tu WordPress y tu servidor, esas guías son tu punto de partida.

Introducción

Si tienes un sitio en WordPress, hay una puerta silenciosa que muchos atacantes intentan forzar: xmlrpc.php. Aunque es una funcionalidad legítima de WordPress, también se ha convertido en un imán para ataques de fuerza bruta, DDoS y explotación de vulnerabilidades.

De hecho, el 60% de los ataques a WordPress aprovechan xmlrpc.php o wp-login.php. Y no es un problema menor: en 2025, se registraron más de 100.000 ataques por segundo contra sitios WordPress en todo el mundo.

La buena noticia: evitar ataques a xmlrpc.php no es complicado si sabes qué medidas aplicar. En esta guía te explico paso a paso cómo proteger tu web sin romper funcionalidades importantes.

Si eres administrador de servidores, también te interesará nuestra Guía Completa de Servidores y nuestra Guía para configurar Fail2ban.

Índice de contenidos

¿Qué es xmlrpc.php?
Por qué es vulnerable
Señales de ataque
Método 1: Desactivar xmlrpc.php
Método 2: Bloquear con Nginx (recomendado)
Método 3: Bloquear con Apache
Método 4: Firewall y WAF
Método 5: Limitar intentos de login
Método 6: Desactivar pingbacks
Método 7: CDN (Cloudflare)
Método 8: Restringir por IP
Verificar que funciona
Monitorización
Mejores prácticas adicionales
FAQ
Conclusión

1. ¿Qué es xmlrpc.php?

xmlrpc.php es un archivo heredado de versiones antiguas de WordPress. Su función original era permitir que aplicaciones externas (como la app móvil de WordPress o servicios como Jetpack) se comunicaran con tu sitio.

Usos legítimos:

Publicar contenido desde apps externas.
Jetpack y otros servicios de WordPress.com.
Gestión móvil del sitio.
Integraciones antiguas de terceros.

Tecnología: usa XML-RPC, un protocolo de llamadas a procedimiento remoto sobre HTTP/XML.

Alternativa moderna: desde WordPress 4.7 (2016), existe la REST API, que ofrece las mismas funcionalidades con mejor seguridad y rendimiento.

Conclusión: en 2026, la mayoría de sitios WordPress no necesitan xmlrpc.php.

2. Por qué es vulnerable

xmlrpc.php presenta varios problemas de seguridad:

2.1 Fuerza bruta amplificada

xmlrpc.php permite enviar cientos de intentos de login en una sola petición HTTP. Esto multiplica la velocidad de los ataques de fuerza bruta:

wp-login.php: 1 intento por petición.
xmlrpc.php: 100-1.000 intentos por petición.

Resultado: un atacante puede probar 1.000 contraseñas en segundos sin levantar sospechas.

2.2 Ataques DDoS mediante pingbacks

Los pingbacks permiten que xmlrpc.php envíe notificaciones entre sitios. Los atacantes usan esto para lanzar DDoS amplificado desde miles de sitios WordPress a la vez.

2.3 Bypass de protecciones

Muchos plugins de seguridad protegen wp-login.php pero olvidan xmlrpc.php. Los atacantes lo usan como puerta trasera para seguir atacando.

2.4 Filtraciones de información

En versiones antiguas, xmlrpc.php podía filtrar información sobre el sitio.

2.5 Vulnerabilidades históricas

CVE-2013-0235: DoS vía XML-RPC.
CVE-2013-0236: manipulación de posts.
CVE-2015-3438: bypass de autenticación.

Aunque están parcheadas, hay implementaciones antiguas vulnerables.

Consulta Zero-day exploits: qué son y cómo protegerte para entender las vulnerabilidades en general.

3. Señales de ataque

Antes de proteger, hay que detectar. Estas son las señales más comunes:

3.1 Señales en el servidor

Picos de tráfico sospechosos en horas inusuales.
Muchas solicitudes POST a /xmlrpc.php.
Lentitud en el servidor sin motivo aparente.
Errores 403 o 500 frecuentes.
Alto uso de CPU en momentos concretos.
IPs repetidas en los logs.

3.2 Cómo comprobar en los logs

# Ver peticiones a xmlrpc.php
grep "xmlrpc.php" /var/log/nginx/access.log

# Contar peticiones por IP
grep "xmlrpc.php" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head

# Ver las últimas 20 peticiones sospechosas
grep "xmlrpc.php" /var/log/nginx/access.log | tail -20

Consulta Análisis de registros en Linux para profundizar.

3.3 Herramientas de detección

Wordfence (plugin WordPress).
Sucuri Security.
Fail2ban (a nivel de servidor).
GoAccess (análisis de logs en tiempo real).

4. Método 1: Desactivar xmlrpc.php

La opción más directa si no usas servicios que dependan de él.

4.1 Desactivar con functions.php

Edita el archivo functions.php de tu tema (o mejor, usa un plugin como Code Snippets):

add_filter('xmlrpc_enabled', '__return_false');

Ventajas:

Desactiva la funcionalidad a nivel de WordPress.
Fácil de implementar.

Desventajas:

El archivo sigue accesible (responde pero no ejecuta).
No protege contra ataques al archivo en sí.

4.2 Desactivar con .htaccess (Apache)

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

4.3 Desactivar con Nginx

Ver Método 2 más abajo.

⚠️ Importante: antes de desactivar, comprueba si usas:

App móvil de WordPress.
Jetpack.
IFTTT u otras integraciones.
Plugins que dependan de XML-RPC.

Si no usas ninguno, desactívalo.

5. Método 2: Bloquear con Nginx (RECOMENDADO)

La mejor solución si usas Nginx como servidor web. Bloquea el acceso antes de que la petición toque WordPress.

5.1 Editar la configuración de Nginx

Edita el archivo de configuración de tu sitio:

sudo nano /etc/nginx/sites-available/tu-dominio.conf

Dentro del bloque server { ... }, añade:

server {
    # ... tus otras configuraciones ...

    # Bloquear el acceso a xmlrpc.php
    location ~* /xmlrpc\.php$ {
        deny all;
        access_log off;
        log_not_found off;
        return 403;
    }

    # ... resto de tu configuración ...
}

Explicación:

location ~* /xmlrpc\.php$ — Captura cualquier petición que termine en xmlrpc.php (case-insensitive).
deny all; — Bloquea el acceso desde cualquier IP.
return 403; — Devuelve «Prohibido».
access_log off; log_not_found off; — Evita que estos ataques llenen tus logs.

5.2 Verificar y recargar Nginx

# Verificar sintaxis
sudo nginx -t

# Si todo está OK, recargar Nginx
sudo systemctl reload nginx

5.3 ¿Por qué 403 y no 404?

Pregunta frecuente: ¿por qué devolver 403 («Prohibido») en lugar de 404 («No encontrado»)?

Respuesta:

404: le dice al atacante que el archivo no existe.
403: le dice al atacante que el archivo existe pero no puede acceder.

Si el atacante ya sabe que usas WordPress (fácil de detectar), devolver 404 no tiene sentido. 403 es más honesto y efectivo.

5.4 ¿Por qué no redirigir?

Tentador pero contraproducente:

Sigue consumiendo recursos: Nginx procesa la petición, ejecuta la redirección, carga la página principal…
No envía el mensaje correcto: un 301/302 no comunica «no puedes acceder».
Confunde a los logs: las redirecciones aparecen como 301/302 en lugar de 403.

Conclusión: bloquear con 403 es la mejor opción.

Consulta nuestra Guía completa para configurar SSL en Nginx si necesitas configurar Nginx desde cero.

6. Método 3: Bloquear con Apache

Si usas Apache, edita el archivo .htaccess en la raíz de tu WordPress y añade:

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

Para versiones antiguas de Apache (2.2):

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

Verificar que funciona

Crea un archivo de prueba con el mismo nombre y comprueba:

curl -I https://tu-dominio.com/xmlrpc.php

Debería devolver:

HTTP/1.1 403 Forbidden

Consulta Cómo instalar servidor Apache2 si necesitas configurar Apache.

7. Método 4: Firewall y WAF

Un firewall web (WAF) añade una capa adicional.

7.1 Firewall a nivel de servidor

UFW:

sudo ufw status
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Fail2ban: analiza logs y bloquea IPs maliciosas automáticamente.

sudo apt install fail2ban
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

Añadir:

[wordpress-xmlrpc]
enabled = true
filter = wordpress-xmlrpc
logpath = /var/log/nginx/access.log
maxretry = 3
bantime = 86400

Consulta Cómo configurar y usar Fail2ban.

7.2 Plugins de seguridad para WordPress

Wordfence: el más popular. Firewall + escaneo + alertas.
Sucuri Security: WAF cloud + monitorización.
iThemes Security: múltiples capas de protección.
WP Cerber: especializado en ataques.

Recomendación: Wordfence gratuito + bloqueo en Nginx.

7.3 ModSecurity (WAF en servidor)

Si usas Nginx/Apache, puedes instalar ModSecurity con reglas OWASP CRS.

Consulta Hardening de servidores web Apache vs Nginx.

8. Método 5: Limitar intentos de login

Bloquea intentos de fuerza bruta tras N fallos.

Plugins

Limit Login Attempts Reloaded.
WP Cerber.
Wordfence (con la opción activada).

Configuración típica

Máximo de intentos: 3-5.
Ventana: 15 minutos.
Bloqueo: 24 horas.

A nivel de servidor

Con Fail2ban, como vimos en el método 4.

Consulta Ataques de fuerza bruta: cómo detectarlos y protegerte.

9. Método 6: Desactivar pingbacks

Los pingbacks permiten que tu sitio notifique a otros cuando los enlazas.

Riesgo: se usan para DDoS amplificado.

Cómo desactivar

Panel de WordPress:
- Ajustes → Comentarios.
- Desmarca: «Permitir notificaciones de enlaces desde otros blogs (pingbacks y trackbacks)».
Vía base de datos:sqlUPDATE wp_options SET option_value = ‘0’ WHERE option_name = ‘default_ping_status’;

Alternativa: solo bloquear pingbacks maliciosos

En functions.php:

add_filter('xmlrpc_methods', function($methods) {
    unset($methods['pingback.ping']);
    unset($methods['pingback.extensions.getPingbacks']);
    return $methods;
});

10. Método 7: CDN (Cloudflare)

Cloudflare filtra tráfico malicioso antes de llegar a tu servidor.

Ventajas

Bloqueo de bots automatizados.
Mitigación de DDoS.
WAF gratuito.
Cache y aceleración.
SSL gratuito.

Configuración básica

Registra tu dominio en Cloudflare.
Cambia los nameservers en tu registrador.
Configura SSL/TLS en «Full (Strict)».
Activa reglas de firewall para bloquear /xmlrpc.php.

Regla personalizada en Cloudflare:

(uri.path eq "/xmlrpc.php") → Block

Consulta Beneficios del uso de CDN para la seguridad y Cómo funciona un CDN.

11. Método 8: Restringir por IP

Si solo necesitas xmlrpc.php para ciertas conexiones (IP de tu oficina, servicios específicos), limita el acceso:

Nginx

location ~* /xmlrpc\.php$ {
    allow 200.100.50.25;      # Tu IP
    allow 200.100.50.26;      # Otra IP autorizada
    deny all;
    return 403;
}

Apache (.htaccess)

<Files "xmlrpc.php">
    Require ip 200.100.50.25
    Require ip 200.100.50.26
</Files>

Resultado: solo las IPs autorizadas pueden acceder.

12. Verificar que funciona

Una vez aplicados los cambios, verifica que el bloqueo funciona:

# Probar con curl
curl -I https://tu-dominio.com/xmlrpc.php

Respuesta esperada:

HTTP/2 403
server: nginx
date: ...
content-type: text/html

Si ves 403 Forbidden, el bloqueo funciona.

Prueba adicional:

# Probar POST (como un atacante)
curl -X POST https://tu-dominio.com/xmlrpc.php

También debería devolver 403.

13. Monitorización

Para confirmar que el bloqueo sigue funcionando:

# Ver peticiones a xmlrpc.php en tiempo real
tail -f /var/log/nginx/access.log | grep xmlrpc

# Contar por IP (ver quién ataca más)
grep "xmlrpc" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head

# Ver solo errores 403 (bloqueados con éxito)
grep "xmlrpc" /var/log/nginx/access.log | grep " 403 " | tail -20

Herramientas útiles:

GoAccess — análisis de logs en tiempo real.
Netdata — monitorización del servidor. Guía
Wordfence — panel de ataques en WordPress.
Fail2ban — bloqueo automático.

Consulta Las mejores herramientas de monitorización de servidores.

14. Mejores prácticas adicionales

Además de bloquear xmlrpc.php, aplica estas medidas:

14.1 Contraseñas robustas

Longitud: 16+ caracteres.
Únicas: nunca reutilizar.
Gestor: Bitwarden, 1Password, KeePass.

Consulta Buenas prácticas en contraseñas y 2FA.

14.2 Autenticación en dos factores (2FA)

Wordfence.
Google Authenticator.
Two Factor Authentication (plugin).

14.3 WordPress actualizado

Core de WordPress.
Plugins.
Temas.
PHP (8.2+).

14.4 Eliminar plugins innecesarios

Cada plugin es una vulnerabilidad potencial.
Desactiva y elimina los que no uses.

14.5 Cambiar la URL de login

WPS Hide Login.
Rename wp-login.php.

14.6 SSL obligatorio

HTTPS en todo el sitio.
HSTS.
Redirect 301 HTTP → HTTPS.

Consulta Guía completa para configurar SSL en Nginx.

14.7 Backups regulares

Backups automáticos diarios.
Almacenamiento offsite.
Pruebas de restauración.

Consulta La importancia de los backups.

14.8 Firewall a nivel de servidor

UFW, firewalld, nftables.

Consulta Cómo configurar firewall en Linux y Firewall en Debian.

14.9 Monitorizar y auditar

Logs revisados regularmente.
Alertas por email/Slack.
Escaneos de seguridad.
Auditorías periódicas.

Consulta Hardening de servidores web.

15. FAQ sobre xmlrpc.php

¿Es seguro desactivar xmlrpc.php?

Sí, siempre que no uses servicios que dependan de él:

App móvil de WordPress.
Jetpack.
Integraciones externas.

Si no los usas, desactivarlo es seguro y recomendado.

¿xmlrpc.php sigue siendo necesario en WordPress?

En la mayoría de casos modernos, no. La REST API ha reemplazado muchas de sus funciones.

Cuándo sigue siendo necesario:

Si usas la app móvil oficial.
Si usas servicios que dependen de XML-RPC (Jetpack, algunos plugins antiguos).
Si tienes integraciones legacy.

En caso de duda, desactívalo y prueba tu sitio. Si algo deja de funcionar, actívalo de nuevo.

¿Qué tipo de ataques usa xmlrpc.php?

Los principales:

Fuerza bruta (múltiples intentos de login en una sola petición).
DDoS mediante pingbacks.
Bypass de protecciones de otros plugins.
Enumeración de usuarios.

¿Un plugin de seguridad es suficiente?

No, en general. Los plugins ayudan, pero la mejor estrategia es defensa en capas:

Bloqueo en Nginx (a nivel de servidor).
Plugin de seguridad (Wordfence, Sucuri).
Fail2ban (a nivel de servidor).
Cloudflare (CDN con WAF).

Cada capa suma.

¿Cómo saber si debo mantener xmlrpc activo?

Actívalo solo si:

Usas la app móvil de WordPress.
Usas Jetpack.
Tienes integraciones externas que lo requieren.
Usas plugins antiguos que dependen de él.

En caso contrario, desactívalo.

¿Bloquear xmlrpc afecta al SEO?

No directamente. Solo afecta a funcionalidades técnicas, no al posicionamiento.

Ojo: si usas Jetpack u otros servicios para optimizar el sitio y esos servicios dependen de xmlrpc.php, podrías afectar indirectamente al rendimiento. Pero el SEO en sí no se ve afectado.

¿Puedo bloquear xmlrpc.php solo para ciertas IPs?

Sí. Configura en Nginx o Apache:

location ~* /xmlrpc\.php$ {
    allow 200.100.50.25;
    deny all;
    return 403;
}

Solo las IPs autorizadas podrán acceder.

¿Qué pasa si uso Apache en lugar de Nginx?

El bloqueo es igual de efectivo:

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

Consulta nuestra Guía de Apache2.

16. Conclusión

xmlrpc.php es un vector de ataque común en WordPress, pero fácil de mitigar si aplicas las medidas correctas.

Resumen de acciones:

Acción	Método	Prioridad
Bloquear en Nginx	Config del servidor	🥇 Alta
Desactivar con functions.php	Código PHP	🥈 Media
WAF (Cloudflare, Wordfence)	Servicio externo	🥇 Alta
Limit intentos login	Plugin	🥈 Media
Desactivar pingbacks	Config WordPress	🥉 Baja
Restringir por IP	Nginx/Apache	🥉 Baja (si aplica)
Monitorizar logs	Fail2ban, GoAccess	🥇 Alta
2FA	Plugin	🥇 Alta
Actualizar WordPress	Rutina	🥇 Alta
Backups	Automatización	🥇 Alta

Estrategia recomendada:

Bloquea xmlrpc.php en Nginx (403).
Instala Wordfence en WordPress.
Configura Fail2ban en el servidor.
Activa Cloudflare como CDN + WAF.
Activa 2FA en todas las cuentas.
Mantén todo actualizado.

Cada capa suma. Juntas convierten tu WordPress en un sitio mucho más resistente.

Si quieres profundizar:

No lo dejes para después. Aplica al menos una de estas medidas hoy mismo y empieza a blindar tu WordPress.