Migrer Uptime Kuma de v1 vers v2 : guide sécurité

Pourquoi migrer maintenant : CVE-2026-45618 et fin de maintenance de la branche 1.x

CVE-2026-45618 est une vulnérabilité critique notée CVSS 10.0 dans LiquidJS, le moteur de gabarits utilisé par Uptime Kuma pour les templates de notifications. Les versions de LiquidJS antérieures à 10.26.0 sont affectées : en exploitant le filtre valueOf dans un champ de template — notamment le nom d'un moniteur — un attaquant peut enchaîner une manipulation de prototype pour atteindre le constructeur Function de JavaScript et exécuter des commandes arbitraires sur l'hôte. Un proof-of-concept public démontre la lecture de fichiers système et l'exécution via child_process.execSync.

La branche 1.x n'a reçu qu'un correctif partiel, limité aux contextes authentifiés : un attaquant disposant d'un accès administrateur — ou capable de le forcer par bruteforce — retrouve la surface d'exploitation initiale. La branche 2.x intègre LiquidJS 10.26.0 et une remédiation complète. Aucun correctif supplémentaire n'est prévu sur la branche 1.x : la version 2.5.0, publiée le 1ᵉʳ août 2026, marque la trajectoire active du projet. Continuer d'opérer une instance 1.x, c'est exposer chaque moniteur — et les clients qu'il surveille — à une surface d'attaque sans date de fermeture connue.

Impacts concrets d'une instance non migrée

Exécution de code à distance : un attaquant qui contrôle le nom d'un moniteur ou un champ de template peut exécuter des commandes système sur le VPS hôte.
Exposition du parc client : une agence qui héberge une instance partagée expose les configurations, les URL internes et les credentials de notification de tous ses clients.
Responsabilité transférée : en cas d'incident sur une instance non maintenue, la négligence à migrer après la publication d'une CVE critique constitue un facteur aggravant.
Accumulation de CVE : la branche 1.x ne recevra plus ni patch de sécurité ni mise à jour de dépendances — chaque nouvelle faille sur LiquidJS ou ses dépendances s'y accumule sans remède.
Détection silencieuse : LiquidJS évalue les gabarits côté serveur ; une exploitation peut rester invisible dans les logs applicatifs d'Uptime Kuma.

Prérequis avant de commencer

Vérifiez les points suivants avant de lancer la migration. Une omission peut rendre le rollback impossible.

Ressources minimales recommandées. Uptime Kuma v2 tourne dans le même gabarit que v1 : 1 vCPU et 512 Mo de RAM suffisent pour moins de 50 moniteurs. Prévoyez 2 vCPU et 1 Go pour un parc de 200 moniteurs ou plus. La migration SQLite peut durer plusieurs minutes sur un stockage lent — un VPS avec SSD NVMe réduit cette fenêtre.

Docker Compose v2. La commande requise est docker compose (plugin intégré), et non docker-compose (binaire autonome v1). Vérifiez avec docker compose version : attendez une réponse commençant par Docker Compose version v2. Si la commande échoue, installez le plugin via le gestionnaire de paquets de votre distribution avant de continuer.

Accès root ou sudo. La procédure manipule des volumes Docker et des fichiers système ; un accès privilégié est indispensable.

Instance v1 opérationnelle. Confirmez la version courante via l'interface web (Paramètres → À propos). La migration suppose que l'instance démarre et que sa base de données est cohérente — si elle est déjà corrompue, restaurez une sauvegarde avant de procéder.

Sauvegarde obligatoire avant la migration

La migration v1 → v2 transforme le schéma de la base SQLite de façon irréversible. Sans sauvegarde valide, un rollback complet est impossible.

Identifier le volume ou le dossier de données. Si vous utilisez Docker Compose avec un volume nommé, le nom par défaut est uptime-kuma_uptime-kuma-data. Confirmez avec docker volume ls | grep kuma. Si vous montez un dossier hôte (bind mount), repérez le chemin dans votre docker-compose.yml — typiquement ./data:/app/data.

Arrêter le conteneur avant la sauvegarde. Une base SQLite sauvegardée pendant une écriture active peut être corrompue. N'utilisez jamais le flag -v lors de l'arrêt : cela supprimerait le volume et son contenu.

Sauvegarde du volume de données

Arrêter Uptime Kuma

Arrêtez le conteneur sans supprimer le volume :

docker compose down

Attendez la confirmation Container uptime-kuma Stopped avant de continuer.

Sauvegarder un volume Docker nommé

Utilisez un conteneur busybox pour créer une archive compressée du volume :

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 .

Vérifiez la taille de l'archive avec ls -lh uptime-kuma-v1-backup.tar.gz. Une archive de quelques octets seulement indique un problème de montage — corrigez avant de continuer.

Sauvegarder un bind mount

Si vos données sont dans un dossier hôte (exemple : ./data) :

tar czf uptime-kuma-v1-backup.tar.gz ./data

Conservez cette archive hors du serveur (stockage objet, serveur distant) avant de passer à la migration.

Migration v1 → v2 : procédure pas à pas

Mettre à jour l'image dans docker-compose.yml

Ouvrez votre fichier docker-compose.yml et remplacez le tag de l'image :

# Avant
image: louislam/uptime-kuma:1
# Après
image: louislam/uptime-kuma:2

Si vous utilisez le tag latest, préférez un tag de version explicite comme louislam/uptime-kuma:2.5.0 pour éviter les régressions lors d'une future montée de version automatique.

Télécharger la nouvelle image

Récupérez l'image v2 avant de démarrer le service :

docker pull louislam/uptime-kuma:2

Vérifiez que l'image est présente : docker images | grep uptime-kuma.

Démarrer le conteneur v2

Lancez le service. Docker Compose détecte le changement d'image et recrée le conteneur :

docker compose up -d

Attendez la confirmation Container uptime-kuma Started.

Suivre la migration de la base de données

Au premier démarrage, Uptime Kuma migre le schéma SQLite vers le format v2. Cette opération peut durer de quelques secondes à plusieurs dizaines de minutes selon la taille de la base :

docker compose logs -f uptime-kuma

N'interrompez pas le conteneur pendant cette phase. Attendez une ligne confirmant la fin de la migration avant de continuer.

Vérifier le healthcheck

Contrôlez que le conteneur est en état healthy :

docker compose ps

La colonne Status doit afficher healthy. Si elle reste sur starting plus de deux minutes après la fin des logs de migration, consultez les logs pour identifier l'erreur.

Confirmer la version active dans l'interface

Connectez-vous à l'interface web. Allez dans Paramètres → À propos et vérifiez que la version affichée commence par 2.. Confirmez que tous vos moniteurs sont présents et que leurs statuts correspondent à l'état réel de vos services.

Vérifications post-migration

Une migration réussie ne se limite pas à un conteneur qui démarre. Parcourez ces points avant de considérer l'opération terminée.

Moniteurs. Ouvrez le tableau de bord et comparez le nombre de moniteurs avec votre inventaire v1. Un moniteur manquant peut indiquer un problème de migration partielle — vérifiez les logs au niveau ERROR ou WARN.

Notifications. Déclenchez manuellement un test de notification pour chaque canal configuré (email, Telegram, webhook). La v2 applique une validation stricte des templates Liquid : un champ contenant des balises non conformes sera rejeté. Profitez-en pour auditer les noms de moniteurs et supprimer tout contenu de template inattendu — c'est le vecteur exact de CVE-2026-45618.

Page de statut. Si vous exposez une page de statut publique, vérifiez qu'elle répond correctement et qu'elle liste les bons services. L'URL et le slug sont conservés après migration.

Certificats SSL. Les sondes TLS redémarrent leur cycle de vérification après migration. Un certificat proche de l'expiration avant la migration peut déclencher immédiatement une alerte : vérifiez la date réelle avant de traiter cela comme une régression.

Durcissement de l'instance après migration

Authentification obligatoire. En v2, l'authentification est activée par défaut. Vérifiez dans Paramètres → Sécurité que l'accès sans mot de passe est désactivé. Sur une instance fraîchement déployée sans compte configuré, l'interface est publiquement accessible pendant la configuration initiale : créez le compte administrateur dans les premières minutes suivant le premier démarrage.

Sous-domaine dédié derrière un reverse proxy. N'exposez pas Uptime Kuma sur un port direct (:3001). Placez-le derrière Nginx ou Caddy sur un sous-domaine dédié (status.votredomaine.com) avec TLS. Fermez le port 3001 au niveau pare-feu : ufw deny 3001.

Fail2ban ou CrowdSec devant le proxy. Ajoutez une règle de détection de bruteforce sur les tentatives de connexion à l'interface. CrowdSec dispose d'un scénario uptime-kuma dans son Hub. Consultez l'article Sécuriser votre VPS avec CrowdSec pour la procédure complète.

Isolation réseau. Placez Uptime Kuma dans un réseau Docker dédié. Il n'a besoin d'accéder qu'aux cibles qu'il surveille — pas aux bases de données de production ni aux APIs internes.

Dépannage : erreurs courantes

Volume incompatible ou base corrompue. Si les logs affichent SQLITE_ERROR: no such table ou database disk image is malformed, la base montée n'est pas valide ou la sauvegarde a été faite avec la base en cours d'écriture. Restaurez l'archive, arrêtez le conteneur proprement, et relancez la procédure depuis l'étape de sauvegarde.

Port 3001 déjà occupé. L'erreur address already in use :::3001 indique qu'un processus utilise déjà ce port. Identifiez-le avec ss -tlnp | grep 3001 et arrêtez-le, ou modifiez le mapping dans docker-compose.yml (par exemple 3002:3001) et mettez à jour la configuration du reverse proxy.

Template de notification rejeté après migration. Si un canal de notification affiche une erreur de template, la validation stricte de LiquidJS 10.26.0 a rejeté un gabarit toléré en v1. Éditez le template concerné dans Paramètres → Notifications et supprimez ou corrigez les balises en erreur.

Certificat TLS affiché comme expiré. Les sondes TLS redémarrent leur cycle après migration. Vérifiez la date réelle avec echo | openssl s_client -connect your-domain.com:443 2>/dev/null | openssl x509 -noout -dates avant de traiter cette alerte comme un incident.

Conteneur en boucle de redémarrage. Si la migration échoue et que la politique est restart: always, Docker relance indéfiniment le conteneur. Passez à restart: no, corrigez le problème dans les logs, puis restaurez la politique d'origine.

Ce que cette migration protège

Migrer vers Uptime Kuma 2.x ferme CVE-2026-45618 sur une surface directement accessible depuis l'interface d'administration. Pour une agence qui gère le parc de plusieurs clients depuis une instance partagée, cette surface est proportionnelle au nombre de comptes et de moniteurs configurés : chaque client supplémentaire élargissait le périmètre exposé.

La v2 apporte aussi des changements structurels qui réduisent la surface d'attaque à long terme : image Docker rootless par défaut, dépendances activement maintenues, et un mécanisme de délai de 14 jours avant l'intégration de nouvelles dépendances npm — pour limiter les attaques sur la chaîne d'approvisionnement, comme le documente l'article Sécuriser la chaîne d'approvisionnement npm en CI.

Gérer et sécuriser l'infrastructure de plusieurs clients depuis un seul espace centralisé, sans porter seul les risques de fin de maintenance, est ce que l'espace agence ServOrbit permet de faire.