LiteSpeed Cache vulnerable: cómo actualizar y qué revisar

LiteSpeed Cache es el plugin de caché que traen de serie casi todos los hostings compartidos españoles que van sobre servidores LiteSpeed, y en los últimos años ha acumulado avisos de seguridad serios. Si quieres saber si el tuyo está en riesgo, la respuesta se resuelve en dos pasos: mirar tu versión, y comprobar si alguien se aprovechó antes de que actualizaras. Este artículo te lleva por los dos, sin rodeos.

Adelanto la conclusión práctica: si tienes activadas las actualizaciones automáticas y el plugin está en su última versión, probablemente estés bien. Lo que hay que descartar es lo que pudo pasar en la ventana de tiempo en que estuviste desactualizado.

Cómo ver tu versión de LiteSpeed Cache en un minuto

Desde el escritorio de WordPress, entra en Plugins → Plugins instalados y busca LiteSpeed Cache. Debajo del nombre verás Versión X.Y y, si hay actualización pendiente, un aviso en la misma fila. Anota el número antes de actualizar: lo vas a necesitar para saber cuánto tiempo estuviste expuesto.

Si no puedes entrar al escritorio, mira el archivo directamente. Por SFTP o desde el gestor de archivos del hosting, abre /wp-content/plugins/litespeed-cache/litespeed-cache.php y busca en la cabecera la línea Version:. También sirve readme.txt del mismo directorio, en la línea Stable tag.

Con acceso por consola es aún más rápido:

wp plugin list --name=litespeed-cache --fields=name,status,version,update,update_version

Un dato que casi nadie mira y que aquí importa: la fecha de la última actualización. Si la carpeta del plugin se modificó hace dos años, has estado desactualizado todo ese tiempo. Con SSH, ls -la wp-content/plugins/litespeed-cache/ te lo dice.

Por qué los plugins de caché tienen más superficie de ataque de lo que parece

Mucha gente asume que un plugin de caché es inofensivo porque «solo guarda copias de las páginas». En la práctica hace bastante más que eso, y cada función añade superficie:

Se ejecuta antes que casi todo lo demás. Para servir una página cacheada hay que interceptar la petición muy pronto, cuando WordPress todavía no ha cargado sus comprobaciones habituales.
Escribe archivos en tu servidor. Guarda páginas renderizadas, CSS y JS combinados, imágenes optimizadas. Cualquier ruta donde un plugin escribe es una ruta que hay que vigilar.
Habla con servicios externos. La optimización de imágenes y la CDN se apoyan en servicios en la nube del fabricante, lo que implica claves, llamadas entrantes y respuestas que hay que validar.
Tiene un rastreador (crawler) que simula usuarios. Para precalentar la caché de páginas que ve un usuario registrado, el plugin necesita hacerse pasar por ese usuario. Esa capacidad, mal protegida, es exactamente lo que un atacante querría.
Puede escribir registros de depuración con cabeceras y cookies dentro. Si ese archivo queda accesible desde la web, estás publicando información de sesión sin saberlo.

No es una crítica al plugin en concreto: es la naturaleza de la pieza. Por eso el criterio para priorizar parches no debe ser cuántas instalaciones tiene el plugin, sino qué permite hacer un fallo suyo. Ese razonamiento, aplicado a todo tu inventario, está desarrollado en la guía sobre vulnerabilidades en plugins de WordPress y cómo saber si te afectan.

Qué puede conseguir un atacante: sesiones, páginas cacheadas y usuarios

Los avisos publicados sobre este plugin en los últimos años apuntan a tres consecuencias distintas, y conviene distinguirlas porque cada una se comprueba de una forma:

Hacerse pasar por un usuario ya identificado. Aprovechando la función de simulación de rol del rastreador, en ciertas configuraciones se podía adoptar la identidad de un usuario, incluido un administrador. La consecuencia final es la de siempre: acceso al escritorio con permisos totales.
Crear un usuario administrador. Cuando el valor que protege una acción sensible se genera de forma poco aleatoria, se puede adivinar y usar. El resultado es una cuenta nueva de administrador que tú no has creado.
Servir contenido de un usuario a otro. Esto no siempre es un ataque: muchas veces es una mala configuración. Si una página con datos personales (el carrito, «mi cuenta», un panel de cliente) se cachea como pública, el siguiente visitante la ve. En una tienda eso puede ser una brecha de datos personales con todas sus consecuencias.

Si te has topado con el aviso concreto y no sabes traducir su gravedad a tu caso, el método para hacerlo está en el artículo sobre cómo leer un aviso de seguridad de un plugin y decidir si te corre prisa: lo que importa es si el fallo requiere estar identificado, qué rol hace falta y si tu web tiene esa función activada.

Cómo actualizar y purgar la caché sin dejar la web a medias

El riesgo de actualizar un plugin de caché no es que rompa la web: es que te deje mezcla de versiones antiguas y nuevas servidas desde la caché, y pases una hora persiguiendo un fantasma. Hazlo en este orden:

Copia de seguridad de archivos y base de datos, descargada y verificada.
Actualiza el plugin desde Plugins → Plugins instalados.
Ve a LiteSpeed Cache → Caja de herramientas y pulsa Purgar todo. Si tu servidor tiene caché de opcode, purga también esa desde la misma pantalla.
Si usas la CDN del fabricante o Cloudflare por delante, purga también ahí. Es el paso que más se olvida.
Si tienes caché de objetos (Redis o Memcached) configurada en LiteSpeed Cache → Caché → Objeto, vacíala igualmente.
Abre la web en una ventana de incógnito y revisa portada, una página interior, el formulario de contacto y, si vendes, el carrito y el proceso de pago completo.

Si la web se descoloca visualmente justo después, casi nunca es el fallo de seguridad: es la combinación de CSS/JS que se rehace. Desactiva temporalmente las opciones de Optimización (combinar CSS, combinar JS, carga diferida), comprueba que vuelve a verse bien y luego reactívalas de una en una. Este es el mismo método de aislamiento que explico con más detalle en la guía sobre cómo actualizar los plugins de WordPress sin romper la web.

Qué revisar después: usuarios administradores y contenido cacheado

Actualizar tapa el agujero. Ahora toca comprobar que nadie pasó por él antes. Media hora bien invertida:

Usuarios → Todos, filtra por Administrador. Si aparece alguna cuenta que no reconoces, o alguna con un correo que no es de tu empresa, no la borres todavía: anota nombre, correo y fecha de registro, porque es la prueba de cuándo entraron. Después bórrala.
Cambia las contraseñas de todos los administradores y regenera las claves de seguridad (salts) de wp-config.php. Eso cierra de golpe todas las sesiones abiertas, incluida la de quien no debería estar dentro.
LiteSpeed Cache → Rastreador: revisa la lista de simulaciones de rol. Si hay entradas que tú no has creado, quítalas. Si no usas el rastreador, desactívalo directamente; es una función que la mayoría de webs pequeñas no necesita.
Desactiva el registro de depuración en LiteSpeed Cache → Depurar si estaba activo, y borra los archivos de registro antiguos. Comprueba desde el navegador que no se puede descargar ninguno escribiendo su ruta.
Comprueba qué se está cacheando de más. Con la sesión iniciada como cliente en otro navegador, entra en «mi cuenta» o el carrito y luego ábrelo en incógnito. Si ves datos de la otra sesión, tienes una fuga de datos personales que hay que corregir hoy: en tiendas, las páginas de carrito, pago y cuenta deben estar excluidas de la caché pública.
Busca archivos PHP donde no toca: find wp-content/uploads -name "*.php" y revisa wp-content/mu-plugins/, que es una carpeta que se carga siempre y que casi nadie mira.

Si encuentras un administrador que no reconoces, no basta con borrarlo: hay que asumir que dejaron algo más y buscar puertas traseras antes de dar la web por limpia. Si no encuentras nada y simplemente ibas desactualizado, actualizar y purgar es todo lo que necesitas hacer. No hace falta contratar a nadie por ir tarde en un parche.

Qué cambia si es tu hosting quien gestiona la caché

En muchos alojamientos españoles la caché la controla el proveedor: te instalan el plugin ya configurado, o lo gestionan desde su propio panel, y a veces te bloquean ciertos ajustes. Eso reparte las responsabilidades, y conviene saber cómo:

Actualizar el plugin sigue siendo, casi siempre, cosa tuya, salvo que tu plan incluya explícitamente actualizaciones gestionadas. Pregúntalo por escrito y guarda la respuesta.
Si el hosting purga desde su panel, purga en los dos sitios tras cada cambio importante.
Si el hosting te ha desactivado opciones del plugin, no las fuerces por código: rompe más de lo que arregla.
Pregunta directamente: ¿quién actualiza este plugin, con qué frecuencia y qué pasa si sale un fallo crítico un viernes por la tarde? La respuesta te dice mucho del proveedor.

Alternativas si tu servidor no es LiteSpeed

Este plugin da su mejor rendimiento cuando el servidor es LiteSpeed u OpenLiteSpeed, porque entonces la caché de página la sirve el propio servidor. Si tu hosting va sobre Apache o nginx clásico, el plugin funciona a medias y quizá estés cargando complejidad (y superficie de ataque) sin la ventaja principal.

Para saber qué servidor tienes, entra en Herramientas → Salud del sitio → Información → Servidor y mira la línea del software del servidor web. Si no aparece LiteSpeed, valora alternativas: WP Super Cache o W3 Total Cache si buscas gratuito, la caché propia del hosting si la ofrece, o una solución de pago si prefieres soporte. Un caso frecuente y peligroso es el del plugin de pago con la licencia caducada, que sigue funcionando pero deja de recibir parches; lo detallo en el artículo sobre qué riesgo asumes con la licencia de WP Rocket caducada, y el razonamiento vale para cualquier plugin comercial.

Y una regla que se aplica a todos: un solo plugin de caché. Dos a la vez no van el doble de rápido, se pisan, y además duplican el sitio donde puede esconderse un problema.

Cuando hayas actualizado y purgado, mira tu web desde fuera para confirmar que todo está donde debe: comprueba gratis el estado de tu WordPress con PathScan. No pide registro, no instala nada y no toca tu web: analiza lo que tu dominio está publicando ahora mismo, que es justo lo que ve un atacante automatizado.

Seguir leyendo en esta sección

Ver todo en Avisos de plugins concretos → · Mapa completo del sitio