[{"data":1,"prerenderedAt":152},["ShallowReactive",2],{"seo-verification":3,"blog-migrer-uptime-kuma-v1-v2-securite-fr":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"id":7,"slug":8,"slugs":9,"title":12,"excerpt":13,"readTime":14,"views":15,"isPinned":16,"publishedAt":17,"category":18,"categories":24,"featuredImage":26,"bgImage":27,"posterImage":28,"relatedSolution":29,"intro":31,"sections":32,"ctaTitle":99,"ctaBody":100,"ctaButton":101,"ctaUrl":102,"relatedPosts":103},289,"migrer-uptime-kuma-v1-v2-securite",{"fr":8,"en":10,"ar":11},"migrating-uptime-kuma-from-v1-to-v2-security-guide","ترقية-uptime-kuma-من-v1-إلى-v2-دليل-الأمان","Migrer Uptime Kuma de v1 vers v2 : guide sécurité","CVE-2026-45618 expose Uptime Kuma 1.x à une exécution de code à distance. Migrez vers v2 et durcissez votre instance avec ce guide pas à pas.",9,0,false,"2026-08-21T00:00:00+00:00",{"id":19,"name":20,"slug":21,"color":22,"icon":23},8,"Sécurité & Monitoring","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[25],{"id":19,"name":20,"slug":21,"color":22,"icon":23},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fmigrer-uptime-kuma-v1-v2-securite-poster.svg",{"categorySlug":21,"appSlug":30},"uptime-kuma","La branche 1.x d'Uptime Kuma ne reçoit plus de correctifs de sécurité. CVE-2026-45618, une faille d'exécution de code à distance dans le moteur de gabarits LiquidJS, a mis en évidence ce risque : sur une instance non migrée, un attaquant peut exécuter des commandes arbitraires. Ce guide conduit la migration vers la version 2.x, sauvegarde les données, détaille les vérifications post-migration et durcit l'instance avant la prochaine tentative d'exploitation.",[33,37,46,49,52,65,86,89,93,96],{"type":34,"title":35,"body":36},"h2","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`.\n\nLa 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.",{"type":38,"title":39,"items":40},"ul","Impacts concrets d'une instance non migrée",[41,42,43,44,45],"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.",{"type":34,"title":47,"body":48},"Prérequis avant de commencer","Vérifiez les points suivants avant de lancer la migration. Une omission peut rendre le rollback impossible.\n\n**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.\n\n**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.\n\n**Accès root ou sudo.** La procédure manipule des volumes Docker et des fichiers système ; un accès privilégié est indispensable.\n\n**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.",{"type":34,"title":50,"body":51},"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.\n\n**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 `.\u002Fdata:\u002Fapp\u002Fdata`.\n\n**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.",{"type":53,"title":54,"steps":55},"steps","Sauvegarde du volume de données",[56,59,62],{"title":57,"body":58},"Arrêter Uptime Kuma","Arrêtez le conteneur sans supprimer le volume :\n```bash\ndocker compose down\n```\nAttendez la confirmation `Container uptime-kuma Stopped` avant de continuer.",{"title":60,"body":61},"Sauvegarder un volume Docker nommé","Utilisez un conteneur busybox pour créer une archive compressée du volume :\n```bash\ndocker run --rm \\\n  --volume uptime-kuma_uptime-kuma-data:\u002Fapp\u002Fdata \\\n  --volume $(pwd):\u002Fbackup \\\n  busybox \\\n  tar czf \u002Fbackup\u002Fuptime-kuma-v1-backup.tar.gz -C \u002Fapp\u002Fdata .\n```\nVé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.",{"title":63,"body":64},"Sauvegarder un bind mount","Si vos données sont dans un dossier hôte (exemple : `.\u002Fdata`) :\n```bash\ntar czf uptime-kuma-v1-backup.tar.gz .\u002Fdata\n```\nConservez cette archive hors du serveur (stockage objet, serveur distant) avant de passer à la migration.",{"type":53,"title":66,"steps":67},"Migration v1 → v2 : procédure pas à pas",[68,71,74,77,80,83],{"title":69,"body":70},"Mettre à jour l'image dans docker-compose.yml","Ouvrez votre fichier `docker-compose.yml` et remplacez le tag de l'image :\n```yaml\n# Avant\nimage: louislam\u002Fuptime-kuma:1\n# Après\nimage: louislam\u002Fuptime-kuma:2\n```\nSi vous utilisez le tag `latest`, préférez un tag de version explicite comme `louislam\u002Fuptime-kuma:2.5.0` pour éviter les régressions lors d'une future montée de version automatique.",{"title":72,"body":73},"Télécharger la nouvelle image","Récupérez l'image v2 avant de démarrer le service :\n```bash\ndocker pull louislam\u002Fuptime-kuma:2\n```\nVérifiez que l'image est présente : `docker images | grep uptime-kuma`.",{"title":75,"body":76},"Démarrer le conteneur v2","Lancez le service. Docker Compose détecte le changement d'image et recrée le conteneur :\n```bash\ndocker compose up -d\n```\nAttendez la confirmation `Container uptime-kuma Started`.",{"title":78,"body":79},"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 :\n```bash\ndocker compose logs -f uptime-kuma\n```\nN'interrompez pas le conteneur pendant cette phase. Attendez une ligne confirmant la fin de la migration avant de continuer.",{"title":81,"body":82},"Vérifier le healthcheck","Contrôlez que le conteneur est en état `healthy` :\n```bash\ndocker compose ps\n```\nLa 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.",{"title":84,"body":85},"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.",{"type":34,"title":87,"body":88},"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.\n\n**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`.\n\n**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.\n\n**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.\n\n**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.",{"type":90,"title":91,"body":92},"tip","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.\n\n**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`.\n\n**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 \u003Ca href=\"\u002Fblog\u002Fsecuriser-vps-crowdsec\">Sécuriser votre VPS avec CrowdSec\u003C\u002Fa> pour la procédure complète.\n\n**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.",{"type":34,"title":94,"body":95},"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.\n\n**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.\n\n**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.\n\n**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>\u002Fdev\u002Fnull | openssl x509 -noout -dates` avant de traiter cette alerte comme un incident.\n\n**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.",{"type":34,"title":97,"body":98},"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é.\n\nLa 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 \u003Ca href=\"\u002Fblog\u002Fsecuriser-chaine-approvisionnement-npm-ci\">Sécuriser la chaîne d'approvisionnement npm en CI\u003C\u002Fa>.\n\nGé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.","Un espace pour gérer l'infrastructure de tous vos clients","L'espace agence ServOrbit centralise domaines, hébergements et VPS de tout votre portefeuille. Vous gérez la relation client, nous tenons l'infrastructure.","Espace agence ServOrbit","\u002Fsolutions\u002Fagences",[104,120,137],{"id":105,"slug":106,"slugs":107,"title":110,"excerpt":111,"readTime":112,"views":15,"isPinned":16,"publishedAt":113,"category":114,"categories":115,"featuredImage":26,"bgImage":27,"posterImage":117,"relatedSolution":118},105,"superviser-vps-uptime-kuma",{"fr":106,"en":108,"ar":109},"monitoring-your-vps-with-uptime-kuma","مراقبة-خادمك-الافتراضي-vps-باستخدام-uptime-kuma","Superviser votre VPS avec Uptime Kuma","Déployez Uptime Kuma sur votre VPS pour surveiller vos sites et services en self-hosted, avec alertes et page de statut publique.",3,"2026-03-07T00:00:00+00:00",{"id":19,"name":20,"slug":21,"color":22,"icon":23},[116],{"id":19,"name":20,"slug":21,"color":22,"icon":23},"\u002Fblog\u002Fcovers\u002Fsuperviser-vps-uptime-kuma-poster.svg",{"categorySlug":119,"appSlug":30},"monitoring",{"id":121,"slug":122,"slugs":123,"title":126,"excerpt":127,"readTime":128,"views":15,"isPinned":16,"publishedAt":129,"category":130,"categories":131,"featuredImage":26,"bgImage":27,"posterImage":133,"relatedSolution":134},108,"securiser-vps-crowdsec",{"fr":122,"en":124,"ar":125},"securing-your-vps-with-crowdsec","تأمين-خادمك-الافتراضي-vps-باستخدام-crowdsec","Sécuriser votre VPS avec CrowdSec","Déployez CrowdSec sur votre VPS pour bloquer les attaques grâce à une détection comportementale et une blocklist communautaire mutualisée.",4,"2026-03-04T00:00:00+00:00",{"id":19,"name":20,"slug":21,"color":22,"icon":23},[132],{"id":19,"name":20,"slug":21,"color":22,"icon":23},"\u002Fblog\u002Fcovers\u002Fsecuriser-vps-crowdsec-poster.svg",{"categorySlug":135,"appSlug":136},"cybersecurity","crowdsec",{"id":138,"slug":139,"slugs":140,"title":143,"excerpt":144,"readTime":128,"views":15,"isPinned":16,"publishedAt":145,"category":146,"categories":147,"featuredImage":26,"bgImage":27,"posterImage":149,"relatedSolution":150},106,"monitoring-vps-grafana-prometheus",{"fr":139,"en":141,"ar":142},"vps-monitoring-with-grafana-and-prometheus","مراقبة-الخادم-الافتراضي-vps-باستخدام-grafana-و-prometheus","Monitoring de VPS avec Grafana et Prometheus","Montez une stack Grafana + Prometheus sur votre VPS pour collecter, stocker et visualiser vos métriques système et applicatives.","2026-03-06T00:00:00+00:00",{"id":19,"name":20,"slug":21,"color":22,"icon":23},[148],{"id":19,"name":20,"slug":21,"color":22,"icon":23},"\u002Fblog\u002Fcovers\u002Fmonitoring-vps-grafana-prometheus-poster.svg",{"categorySlug":119,"appSlug":151},"grafana",1787580983323]