XML-RPC tiene usos legítimos y también superficies de abuso: publicación remota, apps móviles o servicios tipo Jetpack pueden depender de xmlrpc.php. Por eso un bloqueo total solo es seguro cuando sabes que nadie lo necesita.
Identifica qué métodos generan la carga
Mide volumen, origen y tiempo de respuesta de las peticiones. Cuando sea apropiado, utiliza logs de aplicación o inspección de método para saber si el tráfico apunta a autenticación múltiple, pingbacks o una integración real.
Inventaría dependencias antes de restringir
- Apps móviles y publicación remota.
- Jetpack o servicios equivalentes.
- Integraciones externas que todavía utilicen XML-RPC.
- Pingbacks si el sitio los necesita realmente.
system.multicall y pingback.ping no son lo mismo
El primero puede agrupar muchos intentos de autenticación en una sola petición; el segundo puede hacer que el sitio genere conexiones hacia terceros. Hay que limitar el método que causa el riesgo concreto.
Restringe la superficie mínima necesaria
- Aplica rate limiting o bloquea solo métodos no utilizados o abusados.
- Si no existe ninguna dependencia, desactiva el endpoint en la capa edge o servidor.
- Si hubo una autenticación correcta, rota credenciales e invalida sesiones.
- Monitoriza PHP, tráfico saliente y logs después del cambio.
Relaciona XML-RPC con el resto del incidente
Si el patrón es principalmente presión de credenciales, compáralo con el ataque de fuerza bruta con CPU alta. Si alguna cuenta accedió o coinciden cambios en core, añade una comprobación de checksums de WordPress.
No desactives integraciones a ciegas
Un bloqueo de emergencia puede ser correcto, pero documéntalo y prueba los servicios que dependan de XML-RPC. Si una integración es necesaria, limita el método o patrón abusado.
Cómo verificar la restricción
El tráfico hostil ya no debe agotar PHP ni provocar conexiones salientes indeseadas, las integraciones aprobadas deben seguir funcionando y no debe quedar ninguna cuenta o sesión comprometida.