Un sitio WordPress bajo ataque, CPU disparada, MySQL al 100 %, PHP colapsando… y, al final, el culpable no era ni un plugin “pesado” ni una consulta mal indexada. Era algo mucho más sutil: la forma en que algunos plugins de redirección cachean las coincidencias, especialmente cuando se usan reglas con LIKE o expresiones regulares (regex).

Lo que parece una optimización inocente —guardar en caché el resultado de una redirección— puede convertirse en una vulnerabilidad de denegación de servicio en cualquier WordPress que utilice plugins de redirecciones avanzadas, como Rank Math y otros similares.

El caso real: ataques, CDN y una CPU al rojo vivo

El punto de partida es familiar para muchos administradores:

• el sitio lleva semanas bajo ataques constantes,
• se configura un CDN para mitigar el tráfico malicioso,
• pero el servidor sigue hundiéndose en uso de CPU y MySQL.

Al profundizar en la investigación, el administrador descubre algo inquietante:
las fuentes de ataque están lanzando combinaciones aleatorias de URLs que chocan con reglas de redirección configuradas con LIKE o regex. Cada una de esas peticiones:

1. hace que el plugin evalúe las reglas de redirección,
2. genera una coincidencia de patrón,
3. y guarda el resultado en la tabla de caché de redirecciones.

Cuantas más URLs “raras” prueban los bots, más entradas de caché se crean. La tabla crece, las consultas se vuelven más costosas, MySQL se ahoga… y la CPU se dispara.

Cuando el administrador elimina todas las redirecciones basadas en patrones (LIKE/regex) y deja solo redirecciones exactas, la magia ocurre:

El uso de CPU se mantiene constante y bajo, incluso con picos de tráfico.

El CDN sigue ayudando, pero el cuello de botella desaparece porque ya no existe esa combinación explosiva entre ataques y caché de redirección mal diseñada.

Cómo funcionan realmente estos plugins de redirección

La lógica que hay detrás de muchos plugins de redirecciones es más o menos así:

1. Llega una petición a /ruta-cualquiera.
2. El plugin comprueba sus reglas:
   • reglas exactas (/old-page → /new-page),
   • reglas “empieza por…”,
   • reglas con comodines,
   • o reglas con expresiones regulares.
3. Si encuentra una coincidencia, devuelve una redirección (301, 302, etc.).
4. Para no repetir el trabajo la próxima vez, guarda esa coincidencia en una tabla de caché.

Con redirecciones exactas (uno a uno), esto es perfectamente razonable:
si la URL /old-page siempre va a /new-page, tener una caché que recuerde esa decisión ahorra cálculos.

El problema aparece cuando:

• se mezclan reglas de coincidencia parcial (LIKE, comodines, regex),
• el sitio recibe tráfico malicioso o muy agresivo (bots, escáneres, herramientas de fuerza bruta),
• y cada URL distinta genera una nueva entrada en la caché.

Los atacantes no necesitan saber nada de tus reglas de redirección.
Basta con que golpeen:

• /random, /random1, /random2,
• /admin-old, /admin-test, /admin-backup,
• /login-old, /login-backup, etc.

Si alguna de tus reglas con patrones coincide, cada petición genera:

• una evaluación de regex o LIKE (cara para MySQL),
• más una nueva fila en la tabla de caché.

Crecimiento sin control: la tormenta perfecta para MySQL

Lo que se ha observado en este tipo de casos es:

• La tabla de caché de redirecciones empieza a crecer sin límite, con miles o decenas de miles de filas añadidas en poco tiempo.
• Cada nueva petición que pasa por las redirecciones tiene que consultar una tabla cada vez más grande.
• Las operaciones sobre esa tabla (SELECT, INSERT, DELETE) se vuelven lentas.
• MySQL termina saturado, y todo lo que depende de él se resiente:
  • PHP workers se acumulan a la espera,
  • las páginas tardan en generarse,
  • el servidor responde cada vez peor… hasta que, en el peor caso, se cae.

No estamos ante una vulnerabilidad “clásica” de seguridad (no hay robo de datos ni ejecución de código), pero sí ante una vulnerabilidad arquitectónica:
el plugin permite que cualquier atacante fuerce un coste de CPU y de base de datos desproporcionado, simplemente probando muchas URLs distintas.

Lo preocupante es que no es un problema de un solo plugin:
es un patrón de diseño que comparten muchos plugins de redirecciones cuando se combinan:

• caché de resultados,
• con reglas de coincidencia flexible (LIKE, regex, comodines).

La solución adoptada: simplificar o morir

En el caso real analizado, el administrador hizo tres movimientos clave:

1. Desactivar todas las redirecciones con LIKE o regex
   • Se dejaron activos únicamente los redirects de coincidencia exacta (uno a uno).
   • El cambio se aplicó directamente en la base de datos porque el panel de administración apenas respondía.
2. Vaciar la tabla de caché de redirecciones
   • Un TRUNCATE sobre la tabla de caché (por ejemplo, wp_rank_math_redirections_cache en Rank Math) limpió de golpe todas las coincidencias almacenadas.
3. Monitorizar el servidor después del cambio
   • La carga de CPU cayó de forma inmediata.
   • MySQL volvió a niveles normales.
   • El sitio recuperó la estabilidad incluso bajo picos de tráfico.

El mensaje de fondo es claro:
las redirecciones exactas son seguras, las basadas en patrones + caché pueden ser una bomba de relojería.

Recomendaciones para usuarios y administradores de WordPress

A partir de este caso, se pueden extraer varias pautas prácticas:

1. Evitar patrones complejos en plugins de redirección

• No abusar de reglas con comodines, LIKE o regex dentro de WordPress.
• Mantener las redirecciones en su mayoría exactas (/vieja-url → /nueva-url).
• Si se necesitan patrones complejos, limitar su uso y revisarlos periódicamente.

2. Llevar la lógica avanzada fuera de WordPress

• Mover las reglas más pesadas a:
  • el servidor web (NGINX, Apache),
  • o la capa de edge del CDN (Cloudflare, Fastly, etc.).
• Estas capas están mejor preparadas para gestionar reglas de redirección a gran escala sin saturar MySQL.

3. Vigilar el tamaño de las tablas de caché

• Revisar de vez en cuando las tablas de caché de redirecciones que creen los plugins.
• Si crecen de forma anómala, considerar:
  • purgar la tabla,
  • simplificar las reglas,
  • o desactivar las coincidencias por patrones.

4. Combinar con un WAF y limitación de bots

• Usar un firewall de aplicaciones web (WAF) en el CDN o en el servidor para filtrar tráfico claramente malicioso.
• Limitar las peticiones repetitivas desde la misma IP o patrones de escaneo agresivo.

Conclusión

Los plugins de redirección en WordPress son herramientas útiles y, bien configurados, no representan un peligro. Pero cuando se combinan:

• reglas de coincidencia flexible (LIKE, regex, comodines),
• con un sistema de caché que guarda todas las coincidencias,
• y un entorno real lleno de bots, crawlers y ataques automatizados,

pueden convertirse en un punto débil capaz de tumbar un servidor entero.

La lección es simple y valiosa:
si usas plugins de redirecciones en WordPress, revisa qué tipo de redirecciones tienes activas. Mantenerlas lo más exactas posible, vigilar las tablas de caché y empujar la complejidad hacia el servidor o el CDN puede marcar la diferencia entre un sitio estable… y un servidor ardiendo sin que nadie entienda por qué.

Preguntas frecuentes sobre redirecciones en WordPress y uso de CPU

¿Por qué las redirecciones con LIKE o regex en WordPress consumen tanta CPU y MySQL?
Porque cada petición obliga al plugin a evaluar patrones complejos sobre las URLs y, si además se cachea cada coincidencia, se añaden filas sin parar a la tabla de caché. Esa tabla crece, las consultas se vuelven más lentas y MySQL empieza a consumir muchos más recursos.

¿Es seguro usar plugins de redirecciones en WordPress para SEO y migraciones de URL?
Sí, siempre que se usen principalmente redirecciones exactas uno a uno y se eviten reglas con comodines o regex salvo en casos muy controlados. El problema no son las redirecciones en sí, sino la combinación de patrones complejos, caché y ataques automatizados.

¿Cómo puedo detectar si la caché de redirecciones está afectando a mi servidor WordPress?
Algunas señales claras son:

• picos de CPU sin aumento real de tráfico legítimo,
• MySQL constantemente al 80–100 %,
• lentitud general en el backend,
• y tablas de caché de redirecciones con miles o cientos de miles de filas.
  Revisar los logs de consultas y el tamaño de esas tablas ayuda a confirmar el problema.

¿Dónde es mejor aplicar reglas de redirección avanzadas, en WordPress o en el servidor/CDN?
Para sitios con volumen de tráfico medio o alto, es más recomendable definir las reglas avanzadas en NGINX/Apache o en el CDN. Estas capas están optimizadas para manejar redirecciones masivas sin impactar en la base de datos ni en el rendimiento de WordPress.

Referencias: Reddit y martech.zone