Quisieron acelerar su web y acabaron acelerando su hackeo: cómo W3 Total Cache dejó expuestos a un millón de propietarios de WordPress
Ahora incluso un visitante ocasional puede convertirse en el dueño absoluto de tus datos.
La polémica en torno a otro problema en un componente popular del ecosistema de WordPress rápidamente superó el marco de un breve aviso y se convirtió en un análisis detallado con una explotación práctica. Se trata de CVE-2025-9501 en W3 Total Cache, que está instalado en más de 1 millón de sitios.
El hallazgo fue informado primero por el servicio WPScan, que lo describió como la inyección de comandos sin autenticación en versiones de W3 Total Cache anteriores a la 2.8.13. El equipo de RCE Security decidió comprobar hasta qué punto es realista el ataque, examinó el manejo de la caché y reunió un exploit, señalando al autor del informe inicial con el seudónimo 'wcraft'.
La causa de la vulnerabilidad está relacionada con el tratamiento de fragmentos especiales en la página en caché. El mecanismo de etiquetas dinámicas se basa en el valor de la constante W3TC_DYNAMIC_SECURITY, definida en wp-config.php. Si el atacante conoce ese valor secreto, es posible sustituir el contenido de modo que llegue a la sección donde se ejecuta eval y provoque la ejecución remota de código.
Cabe señalar que los ataques sin autenticación no siempre son posibles. Según RCE Security, para un escenario sin inicio de sesión en el sitio deben concurrir varias condiciones. Por ejemplo, en el sitio deben estar habilitados los comentarios para usuarios no autenticados, además de estar activada la función Page Cache, que en el plugin viene desactivada por defecto pero es una función clave de W3 Total Cache. Si se incumple al menos uno de estos requisitos, el riesgo disminuye, y en varias configuraciones el problema de hecho se convierte en una vulnerabilidad que requiere autenticación.
Se destaca además la historia de los intentos de corrección. En las versiones 2.8.13, 2.8.14 y 2.8.15 los desarrolladores añadieron la limpieza de fragmentos peligrosos, pero debido a la lógica de sustitución del token y las diferencias en las expresiones regulares el filtro podía ser eludido. En la versión 2.9.1, según el análisis, no se introdujeron cambios que cerraran el vector de ataque, por lo que la explotación sigue siendo posible si se dan las condiciones necesarias.