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

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 gabarit — dans Uptime Kuma, le modèle de message d'une notification — 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 aucun correctif : sa dernière version, 1.23.17 (octobre 2025), embarque LiquidJS 10.22.0, et le projet marque désormais les tags Docker 1 et latest comme dépréciés. Modifier un gabarit de notification demande un compte : un attaquant qui obtient un accès administrateur — par vol d'identifiants ou par bruteforce — dispose de cette surface. La branche 2.x intègre LiquidJS 10.26.0 depuis la version 2.4.0 (mai 2026) et continue de recevoir des correctifs : la 2.5.8 a par exemple corrigé une exécution de code authentifiée via Apprise (GHSA-v2p3-6f5h-6hhf) qui touche aussi toute la branche 1.x. La dernière version, 2.5.9, est sortie en octobre 2026. 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.

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

Ressources minimales recommandées. La documentation d'Uptime Kuma ne fixe pas de minimum chiffré : une petite instance tient sur un VPS d'entrée de gamme, mais la RAM et le disque croissent avec le nombre de moniteurs et l'historique conservé. La migration agrège la table des heartbeats : le mainteneur rapporte environ 7 minutes pour 20 moniteurs et 90 jours de données, et plusieurs heures sur un matériel 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 version 2 ou ultérieure (la branche actuelle est la v5). 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.

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é, son nom complet combine le nom du projet Compose et celui du volume, par exemple 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.

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). En v2, les gabarits de l'e-mail (SMTP) passent d'un remplacement par expression régulière à LiquidJS : les variables deviennent sensibles à la casse et une variable inconnue est ignorée sans erreur. Profitez-en pour auditer le gabarit de chaque notification et supprimer tout contenu inattendu (balises {% %}, filtre valueOf) — c'est le vecteur 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.

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é. Une erreur port is already allocated ou address already in use sur le port 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 127.0.0.1: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, le gabarit contient une syntaxe que LiquidJS refuse ; en v1, l'e-mail SMTP n'utilisait pas LiquidJS mais un simple remplacement par expression régulière. É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 -servername your-domain.com 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 ou unless-stopped, Docker relance indéfiniment le conteneur. Passez à restart: "no" (entre guillemets en YAML), corrigez le problème dans les logs, puis restaurez la politique d'origine.

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 : des images Docker rootless proposées en option (tags 2-rootless), des dépendances activement maintenues, et un délai de 14 jours avant l'intégration de nouvelles versions de dépendances npm (min-release-age=14 dans le .npmrc du projet) — pour limiter les attaques sur la chaîne d'approvisionnement.

Avec une offre Agency ServOrbit.com, vous créez et suivez les comptes cPanel de vos clients depuis un seul espace.