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 una plantilla —en Uptime Kuma, la plantilla del mensaje de una notificación— 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 no recibió ninguna corrección: su última versión, 1.23.17 (octubre de 2025), incluye LiquidJS 10.22.0, y el proyecto marca ahora los tags Docker 1 y latest como obsoletos. Modificar una plantilla de notificación requiere una cuenta: un atacante que obtenga acceso de administrador —por robo de credenciales o por fuerza bruta— dispone de esa superficie. La rama 2.x incorpora LiquidJS 10.26.0 desde la versión 2.4.0 (mayo de 2026) y sigue recibiendo correcciones: la 2.5.8, por ejemplo, corrigió una ejecución de código autenticada mediante Apprise (GHSA-v2p3-6f5h-6hhf) que afecta también a toda la rama 1.x. La última versión, 2.5.9, salió en octubre de 2026. 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 pueda modificar una plantilla de notificación 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. La documentación de Uptime Kuma no fija ninguna cifra: una instancia pequeña cabe en un VPS de gama de entrada, pero la RAM y el disco crecen con el número de monitores y el historial conservado. La migración agrega la tabla de heartbeats: el mantenedor indica unos 7 minutos para 20 monitores y 90 días de datos, y varias horas en un hardware 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 la versión 2 o posterior (la rama actual es la v5). 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, su nombre completo combina el nombre del proyecto Compose y el del volumen, por ejemplo 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.9(última versión, octubre de 2026) para evitar regresiones en una futura actualización automática de versión, y siga los avisos de seguridad del repositorio para actualizarlo. Evite los tagsrootlesspara esta migración: la guía oficial los desaconseja al venir de v1.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 horas según el tamaño de la base y la velocidad del hardware:
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). En v2, las plantillas del email (SMTP) pasan de un reemplazo por expresión regular a LiquidJS: las variables distinguen mayúsculas y minúsculas y una variable desconocida se ignora sin error. Aproveche para auditar la plantilla de cada notificación y eliminar cualquier contenido inesperado (etiquetas {% %}, filtro valueOf): es el vector 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. Un ufw deny 3001 no basta: los puertos publicados por Docker eluden las reglas de ufw. Publique el puerto solo en la interfaz local en docker-compose.yml ("127.0.0.1:3001:3001") para que solo el reverse proxy lo alcance.
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. El Hub de CrowdSec ofrece una colección comunitaria, timokoessler/uptime-kuma, con un escenario de fuerza bruta. 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. Un error port is already allocated o address already in use en el puerto 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 127.0.0.1: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 plantilla contiene una sintaxis que LiquidJS rechaza; en v1, el email SMTP no usaba LiquidJS sino un simple reemplazo por expresión regular. 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 -servername your-domain.com 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 o unless-stopped, Docker reinicia el contenedor indefinidamente. Cambie a restart: "no" (entre comillas en YAML), 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: imágenes Docker rootless ofrecidas como opción (tags 2-rootless), dependencias mantenidas activamente y una espera de 14 días antes de incorporar nuevas versiones de dependencias npm (min-release-age=14 en el .npmrc del proyecto), para limitar los ataques a la cadena de suministro.
Con una oferta Agency de ServOrbit.com, crea y sigue las cuentas cPanel de sus clientes desde un solo espacio.
