Cómo bloquear los ataques de fuerza bruta a xmlrpc.php en WordPress

Reconocer un ataque XML-RPC en los logs de acceso

Cuenta las peticiones POST a xmlrpc.php por dirección. Un sitio normal recibe unas pocas al día, de Jetpack o de una app. Cientos desde una misma dirección, o un flujo constante desde muchas, es un ataque.

sudo sh -c "grep -hI 'POST /xmlrpc.php' /var/log/nginx/*access*.log /var/log/apache2/*access*.log \
  /var/log/httpd/*access_log /usr/local/apache/domlogs/* /var/log/apache2/domlogs/* 2>/dev/null" \
  | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

El comando lee los sitios habituales: nginx, Apache en Debian y Ubuntu, httpd en la familia RHEL y los logs por dominio de cPanel. Las peticiones por hora muestran cuándo empezó:

sudo sh -c "grep -hI 'POST /xmlrpc.php' /var/log/nginx/access.log /var/log/apache2/access.log /var/log/httpd/access_log 2>/dev/null" \
  | awk '{print substr($4, 2, 14)}' | uniq -c | tail -n 24

• El código de estado es 200 incluso con una contraseña incorrecta: XML-RPC informa del fallo dentro de la respuesta. No interpretes 200 como un inicio de sesión correcto.
• Las respuestas grandes, repetidas desde una misma dirección cada pocos segundos, suelen ser system.multicall: una respuesta para muchos intentos de contraseña.
• El log no muestra qué método se llamó: el cuerpo de la petición no se registra. Aquí la fuerza bruta y el abuso de pingbacks se ven igual.

Para saber si XML-RPC responde en un sitio, pídele su lista de métodos desde cualquier máquina. Una lista de métodos significa que está activo; un 403, que está bloqueado.

curl -s -X POST -H 'Content-Type: text/xml' \
  -d '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>' \
  https://example.com/xmlrpc.php | head -c 400; echo

Bloquear xmlrpc.php en nginx o Apache

Bloquear en el servidor web es la opción más barata: la petición se rechaza antes de que carguen PHP y WordPress. En nginx, añade esto al bloque server de cada sitio WordPress:

# In the site's server { } block, before the "location ~ \.php$" block
location = /xmlrpc.php {
    deny all;
}

sudo nginx -t && sudo systemctl reload nginx

En Apache 2.4, ponlo en el .htaccess del sitio (no hace falta recargar; LiteSpeed también lo lee) o en su <VirtualHost>:

# In the site's .htaccess or <VirtualHost>
<Files "xmlrpc.php">
    Require all denied
</Files>

sudo apachectl configtest && sudo systemctl reload apache2

sudo apachectl configtest && sudo systemctl reload httpd

Desactivar XML-RPC dentro de WordPress

Donde no puedes cambiar la configuración del servidor web, un plugin de uso obligatorio (mu-plugin) lo hace desde WordPress. Los mu-plugins se cargan en cada petición y no se pueden desactivar por error desde el panel de administración. Sustituye la ruta por la de tu sitio:

sudo mkdir -p /var/www/example.com/wp-content/mu-plugins
sudo tee /var/www/example.com/wp-content/mu-plugins/disable-xmlrpc.php > /dev/null <<'EOF'
<?php
// Turns off the XML-RPC methods that need a login, and pingbacks.
add_filter( 'xmlrpc_enabled', '__return_false' );
add_filter( 'xmlrpc_methods', function ( $methods ) {
    unset( $methods['pingback.ping'], $methods['pingback.extensions.getPingbacks'] );
    return $methods;
} );
EOF

Los plugins hacen lo mismo: plugins dedicados del tipo "Disable XML-RPC", y plugins de seguridad como Wordfence y Solid Security tienen una opción para ello (a noviembre de 2026). Un plugin se desactiva fácilmente por accidente durante una actualización; el mu-plugin y la regla del servidor web no.

Mantener Jetpack funcionando

Jetpack se comunica con tu sitio a través de xmlrpc.php, así que bloquearlo para todos rompe la conexión de Jetpack. Jetpack publica los rangos de direcciones que usan sus servidores en su página de lista de permitidos: permítelos y bloquea al resto. En nginx, la location debe además pasar la petición a PHP:

location = /xmlrpc.php {
    # Jetpack's ranges, from its allowlist page (check it for changes)
    allow 122.248.245.244/32;
    allow 54.217.201.243/32;
    allow 54.232.116.4/32;
    allow 192.0.64.0/18;
    allow 195.234.108.0/22;
    deny all;
    # then the same lines as in your "location ~ \.php$" block, for example:
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_pass unix:/run/php/php-fpm.sock;
}

Copia las líneas de PHP del propio bloque location ~ \.php$ del sitio: la ruta del socket cambia de un sistema a otro. En Apache, Require ip por sí solo permite únicamente esos rangos:

<Files "xmlrpc.php">
    Require ip 122.248.245.244/32 54.217.201.243/32 54.232.116.4/32 192.0.64.0/18 195.234.108.0/22
</Files>

Limitar la frecuencia de xmlrpc.php cuando debe seguir abierto

Si una app o un servicio que no puedes identificar por dirección necesita XML-RPC, limita la frecuencia con la que cada dirección puede llamarlo. En nginx, define una zona en el contexto http y úsala para xmlrpc.php: aquí 6 peticiones por minuto y dirección, con una ráfaga de 5, y 429 por encima de eso.

# /etc/nginx/conf.d/xmlrpc-limit.conf (read inside the http { } block)
limit_req_zone $binary_remote_addr zone=xmlrpc:10m rate=6r/m;

# In the site's server { } block
location = /xmlrpc.php {
    limit_req zone=xmlrpc burst=5 nodelay;
    limit_req_status 429;
    # then the same lines as in your "location ~ \.php$" block, for example:
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_pass unix:/run/php/php-fpm.sock;
}

sudo nginx -t && sudo systemctl reload nginx

Banear a los atacantes de XML-RPC con fail2ban

fail2ban lee el log de acceso y banea una dirección en el firewall, así que funciona igual con nginx que con Apache. Instálalo como en Cómo frenar los ataques de fuerza bruta SSH (repositorios de Debian y Ubuntu, EPEL en la familia RHEL). Después crea un filtro para las peticiones POST a xmlrpc.php:

sudo tee /etc/fail2ban/filter.d/wordpress-xmlrpc.conf > /dev/null <<'EOF'
[Definition]
failregex = ^<HOST> \S+ \S+ \[[^]]+\] "POST /xmlrpc\.php
ignoreregex =
EOF

Y una jail: 5 peticiones en 60 segundos, un baneo de una hora. Pon tu propia dirección en ignoreip y, si usas Jetpack, sus rangos. Para Apache, pon en logpath /var/log/apache2/*access.log en Debian y Ubuntu o /var/log/httpd/*access_log en la familia RHEL.

sudo tee /etc/fail2ban/jail.d/wordpress-xmlrpc.local > /dev/null <<'EOF'
[wordpress-xmlrpc]
enabled  = true
port     = http,https
filter   = wordpress-xmlrpc
logpath  = /var/log/nginx/access.log
maxretry = 5
findtime = 60
bantime  = 3600
ignoreip = 127.0.0.1/8 ::1 192.0.2.10
EOF

Prueba el filtro con el log real antes de activarlo: fail2ban-regex muestra cuántas líneas coinciden. Después reinicia fail2ban y comprueba la jail.

sudo fail2ban-regex /var/log/nginx/access.log /etc/fail2ban/filter.d/wordpress-xmlrpc.conf
sudo systemctl restart fail2ban
sudo fail2ban-client status wordpress-xmlrpc

Preguntas

¿Es seguro desactivar xmlrpc.php?

Para la mayoría de los sitios, sí: el editor de bloques y el panel de administración usan la API REST, no XML-RPC. Comprueba antes si usas Jetpack, pingbacks, una app o una herramienta de publicación que todavía dependa de él.

¿Por qué los ataques aparecen con estado 200?

XML-RPC responde 200 e informa del inicio de sesión fallido dentro de la respuesta. El código de estado no dice nada sobre si una contraseña funcionó.

Mi plugin limitador de inicios de sesión no lo detiene. ¿Por qué?

Muchos limitadores cuentan los intentos en wp-login.php. Una petición system.multicall a través de xmlrpc.php lleva cientos de intentos en una sola petición y los esquiva. Bloquea o limita el propio xmlrpc.php.