Por qué migrar ahora: CVE-2026-45618 y fin del mantenimiento de la rama 1.x
CVE-2026-45618 es una vulnerabilidad crítica con puntuación CVSS 10.0 en LiquidJS, el motor de plantillas que Uptime Kuma utiliza para las plantillas de notificación. Las versiones de LiquidJS anteriores a la 10.26.0 están afectadas: al explotar el filtro valueOf en un campo de plantilla —en particular el nombre de un monitor— un atacante puede encadenar una manipulación de prototipos para alcanzar el constructor Function de JavaScript y ejecutar comandos arbitrarios en el host. Una prueba de concepto pública demuestra la lectura de archivos del sistema y la ejecución mediante child_process.execSync.
La rama 1.x solo recibió una corrección parcial, limitada a los contextos autenticados: un atacante con acceso de administrador —o capaz de forzarlo por fuerza bruta— recupera la superficie de explotación inicial. La rama 2.x incorpora LiquidJS 10.26.0 y una remediación completa. No se prevé ninguna corrección adicional en la rama 1.x: la versión 2.5.0, publicada el 1 de agosto de 2026, marca la trayectoria activa del proyecto. Seguir operando una instancia 1.x significa exponer cada monitor —y los clientes a los que vigila— a una superficie de ataque sin fecha de cierre conocida.
Impactos concretos de una instancia sin migrar
- Ejecución remota de código: un atacante que controle el nombre de un monitor o un campo de plantilla puede ejecutar comandos del sistema en el VPS anfitrión.
- Exposición del parque de clientes: una agencia que aloja una instancia compartida expone las configuraciones, las URL internas y las credenciales de notificación de todos sus clientes.
- Responsabilidad trasladada: en caso de incidente en una instancia sin mantenimiento, la negligencia de no migrar tras la publicación de una CVE crítica constituye un factor agravante.
- Acumulación de CVE: la rama 1.x ya no recibirá parches de seguridad ni actualizaciones de dependencias; cada nuevo fallo en LiquidJS o en sus dependencias se acumula allí sin remedio.
- Detección silenciosa: LiquidJS evalúa las plantillas del lado del servidor; una explotación puede permanecer invisible en los logs de aplicación de Uptime Kuma.
Requisitos previos antes de empezar
Compruebe los siguientes puntos antes de iniciar la migración. Una omisión puede hacer imposible el rollback.
Recursos mínimos recomendados. Uptime Kuma v2 funciona con el mismo perfil de recursos que v1: 1 vCPU y 512 MB de RAM bastan para menos de 50 monitores. Prevea 2 vCPU y 1 GB para un parque de 200 monitores o más. La migración de SQLite puede durar varios minutos en un almacenamiento lento: un VPS con SSD NVMe reduce esa ventana.
Docker Compose v2. El comando requerido es docker compose (plugin integrado), y no docker-compose (binario autónomo v1). Compruébelo con docker compose version: espere una respuesta que empiece por Docker Compose version v2. Si el comando falla, instale el plugin mediante el gestor de paquetes de su distribución antes de continuar.
Acceso root o sudo. El procedimiento manipula volúmenes Docker y archivos del sistema; un acceso privilegiado es indispensable.
Instancia v1 operativa. Confirme la versión actual desde la interfaz web (Configuración → Acerca de). La migración presupone que la instancia arranca y que su base de datos es coherente: si ya está dañada, restaure una copia de seguridad antes de proceder.
Copia de seguridad obligatoria antes de la migración
La migración v1 → v2 transforma el esquema de la base SQLite de forma irreversible. Sin una copia de seguridad válida, un rollback completo es imposible.
Identificar el volumen o la carpeta de datos. Si utiliza Docker Compose con un volumen con nombre, el nombre por defecto es uptime-kuma_uptime-kuma-data. Confírmelo con docker volume ls | grep kuma. Si monta una carpeta del host (bind mount), localice la ruta en su docker-compose.yml: normalmente ./data:/app/data.
Detener el contenedor antes de la copia. Una base SQLite copiada mientras hay escrituras activas puede quedar dañada. No utilice nunca el flag -v al detenerla: eliminaría el volumen y su contenido.
Copia de seguridad del volumen de datos
Detener Uptime Kuma
Detenga el contenedor sin eliminar el volumen:
docker compose downEspere la confirmación
Container uptime-kuma Stoppedantes de continuar.Copiar un volumen Docker con nombre
Utilice un contenedor busybox para crear un archivo comprimido del volumen:
docker run --rm \ --volume uptime-kuma_uptime-kuma-data:/app/data \ --volume $(pwd):/backup \ busybox \ tar czf /backup/uptime-kuma-v1-backup.tar.gz -C /app/data .Compruebe el tamaño del archivo con
ls -lh uptime-kuma-v1-backup.tar.gz. Un archivo de solo unos pocos bytes indica un problema de montaje: corríjalo antes de continuar.Copiar un bind mount
Si sus datos están en una carpeta del host (por ejemplo:
./data):tar czf uptime-kuma-v1-backup.tar.gz ./dataGuarde este archivo fuera del servidor (almacenamiento de objetos, servidor remoto) antes de pasar a la migración.
Migración v1 → v2: procedimiento paso a paso
Actualizar la imagen en docker-compose.yml
Abra su archivo
docker-compose.ymly sustituya el tag de la imagen:# Antes image: louislam/uptime-kuma:1 # Después image: louislam/uptime-kuma:2Si utiliza el tag
latest, prefiera un tag de versión explícito comolouislam/uptime-kuma:2.5.0para evitar regresiones en una futura actualización automática de versión.Descargar la nueva imagen
Obtenga la imagen v2 antes de arrancar el servicio:
docker pull louislam/uptime-kuma:2Compruebe que la imagen está presente:
docker images | grep uptime-kuma.Arrancar el contenedor v2
Inicie el servicio. Docker Compose detecta el cambio de imagen y recrea el contenedor:
docker compose up -dEspere la confirmación
Container uptime-kuma Started.Seguir la migración de la base de datos
En el primer arranque, Uptime Kuma migra el esquema SQLite al formato v2. Esta operación puede durar desde unos segundos hasta varias decenas de minutos según el tamaño de la base:
docker compose logs -f uptime-kumaNo interrumpa el contenedor durante esta fase. Espere una línea que confirme el final de la migración antes de continuar.
Comprobar el healthcheck
Compruebe que el contenedor está en estado
healthy:docker compose psLa columna
Statusdebe mostrarhealthy. Si permanece enstartingmás de dos minutos después del final de los logs de migración, consulte los logs para identificar el error.Confirmar la versión activa en la interfaz
Conéctese a la interfaz web. Vaya a Configuración → Acerca de y compruebe que la versión mostrada empieza por
2.. Confirme que todos sus monitores están presentes y que sus estados corresponden al estado real de sus servicios.
Comprobaciones posteriores a la migración
Una migración correcta no se limita a un contenedor que arranca. Repase estos puntos antes de dar la operación por terminada.
Monitores. Abra el panel y compare el número de monitores con su inventario v1. Un monitor ausente puede indicar un problema de migración parcial: revise los logs de nivel ERROR o WARN.
Notificaciones. Lance manualmente una notificación de prueba para cada canal configurado (email, Telegram, webhook). La v2 aplica una validación estricta de las plantillas Liquid: un campo con etiquetas no conformes será rechazado. Aproveche para auditar los nombres de los monitores y eliminar cualquier contenido de plantilla inesperado: es el vector exacto de CVE-2026-45618.
Página de estado. Si expone una página de estado pública, compruebe que responde correctamente y que lista los servicios correctos. La URL y el slug se conservan tras la migración.
Certificados SSL. Las sondas TLS reinician su ciclo de verificación tras la migración. Un certificado próximo a caducar antes de la migración puede disparar una alerta de inmediato: compruebe la fecha real antes de tratarlo como una regresión.
Refuerzo de la instancia tras la migración
Autenticación obligatoria. En v2, la autenticación está activada por defecto. Compruebe en Configuración → Seguridad que el acceso sin contraseña está desactivado. En una instancia recién desplegada y sin cuenta configurada, la interfaz es públicamente accesible durante la configuración inicial: cree la cuenta de administrador en los primeros minutos tras el primer arranque.
Subdominio dedicado detrás de un reverse proxy. No exponga Uptime Kuma en un puerto directo (:3001). Colóquelo detrás de Nginx o Caddy en un subdominio dedicado (status.sudominio.com) con TLS. Cierre el puerto 3001 en el firewall: ufw deny 3001.
Fail2ban o CrowdSec delante del proxy. Añada una regla de detección de fuerza bruta sobre los intentos de conexión a la interfaz. CrowdSec dispone de un escenario uptime-kuma en su Hub. Consulte el artículo Proteger su VPS con CrowdSec para el procedimiento completo.
Aislamiento de red. Coloque Uptime Kuma en una red Docker dedicada. Solo necesita acceder a los objetivos que supervisa, no a las bases de datos de producción ni a las API internas.
Solución de problemas: errores frecuentes
Volumen incompatible o base dañada. Si los logs muestran SQLITE_ERROR: no such table o database disk image is malformed, la base montada no es válida o la copia se hizo con la base en plena escritura. Restaure el archivo, detenga el contenedor correctamente y reinicie el procedimiento desde el paso de copia de seguridad.
Puerto 3001 ya ocupado. El error address already in use :::3001 indica que un proceso ya utiliza ese puerto. Identifíquelo con ss -tlnp | grep 3001 y deténgalo, o modifique el mapeo en docker-compose.yml (por ejemplo 3002:3001) y actualice la configuración del reverse proxy.
Plantilla de notificación rechazada tras la migración. Si un canal de notificación muestra un error de plantilla, la validación estricta de LiquidJS 10.26.0 ha rechazado una plantilla que v1 toleraba. Edite la plantilla afectada en Configuración → Notificaciones y elimine o corrija las etiquetas erróneas.
Certificado TLS mostrado como caducado. Las sondas TLS reinician su ciclo tras la migración. Compruebe la fecha real con echo | openssl s_client -connect your-domain.com:443 2>/dev/null | openssl x509 -noout -dates antes de tratar esta alerta como un incidente.
Contenedor en bucle de reinicio. Si la migración falla y la política es restart: always, Docker reinicia el contenedor indefinidamente. Cambie a restart: no, corrija el problema a partir de los logs y después restaure la política original.
Qué protege esta migración
Migrar a Uptime Kuma 2.x cierra CVE-2026-45618 en una superficie directamente accesible desde la interfaz de administración. Para una agencia que gestiona el parque de varios clientes desde una instancia compartida, esa superficie es proporcional al número de cuentas y de monitores configurados: cada cliente adicional ampliaba el perímetro expuesto.
La v2 aporta además cambios estructurales que reducen la superficie de ataque a largo plazo: imagen Docker rootless por defecto, dependencias mantenidas activamente y un mecanismo de espera de 14 días antes de incorporar nuevas dependencias npm, para limitar los ataques a la cadena de suministro, como documenta el artículo Proteger la cadena de suministro npm en CI.
Gestionar y proteger la infraestructura de varios clientes desde un único espacio centralizado, sin cargar en solitario con los riesgos del fin de mantenimiento, es lo que permite el espacio de agencia de ServOrbit.
