[{"data":1,"prerenderedAt":152},["ShallowReactive",2],{"seo-verification":3,"blog-migrating-uptime-kuma-from-v1-to-v2-security-guide-en":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,"migrating-uptime-kuma-from-v1-to-v2-security-guide",{"fr":10,"en":8,"ar":11},"migrer-uptime-kuma-v1-v2-securite","ترقية-uptime-kuma-من-v1-إلى-v2-دليل-الأمان","Migrating Uptime Kuma from v1 to v2: security guide","CVE-2026-45618 exposes Uptime Kuma 1.x to remote code execution. Migrate to v2 and harden your instance with this step-by-step guide.",9,0,false,"2026-08-21T00:00:00+00:00",{"id":19,"name":20,"slug":21,"color":22,"icon":23},8,"Security & 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","The Uptime Kuma 1.x branch no longer receives security patches. CVE-2026-45618, a remote code execution flaw in the LiquidJS template engine, made this risk concrete: on an unpatched instance, an attacker can run arbitrary commands. This guide walks through the migration to version 2.x, covers data backup, post-migration checks, and hardens the instance before the next exploitation attempt.",[33,37,46,49,52,65,86,89,93,96],{"type":34,"title":35,"body":36},"h2","Why migrate now: CVE-2026-45618 and end of maintenance for the 1.x branch","CVE-2026-45618 is a critical vulnerability scored CVSS 10.0 in LiquidJS, the template engine used by Uptime Kuma for notification templates. LiquidJS versions prior to 10.26.0 are affected: by exploiting the `valueOf` filter in a template field — such as a monitor name — an attacker can chain prototype manipulation to reach JavaScript's `Function` constructor and execute arbitrary commands on the host. A public proof-of-concept demonstrates file reads and execution via `child_process.execSync`.\n\nThe 1.x branch received only a partial fix, scoped to authenticated contexts: an attacker with admin access — or able to force it through bruteforce — retains the original attack surface. The 2.x branch ships LiquidJS 10.26.0 with a complete remediation. No further patches are planned for the 1.x branch: version 2.5.0, released August 1, 2026, marks the active trajectory of the project. Running a 1.x instance means exposing every monitor — and the clients it watches — to an attack surface with no known closure date.",{"type":38,"title":39,"items":40},"ul","Concrete impacts of an unmigrated instance",[41,42,43,44,45],"Remote code execution: an attacker who controls a monitor name or template field can run system commands on the host VPS.","Client portfolio exposure: an agency hosting a shared instance exposes the configurations, internal URLs, and notification credentials of all its clients.","Transferred liability: in the event of an incident on an unmaintained instance, failure to migrate after a critical CVE is published constitutes an aggravating factor.","CVE accumulation: the 1.x branch receives neither security patches nor dependency updates — every new flaw in LiquidJS or its dependencies accumulates without remedy.","Silent detection: LiquidJS evaluates templates server-side; exploitation may remain invisible in Uptime Kuma application logs.",{"type":34,"title":47,"body":48},"Prerequisites before you start","Check the following points before starting the migration. Missing one can make rollback impossible.\n\n**Minimum recommended resources.** Uptime Kuma v2 runs in the same footprint as v1: 1 vCPU and 512 MB of RAM are sufficient for under 50 monitors. Plan for 2 vCPU and 1 GB for a fleet of 200 monitors or more. SQLite migration can take several minutes on slow storage — a VPS with NVMe SSD reduces this window.\n\n**Docker Compose v2.** The required command is `docker compose` (integrated plugin), not `docker-compose` (standalone v1 binary). Check with `docker compose version`: expect a response starting with `Docker Compose version v2`. If the command fails, install the plugin via your distribution's package manager before continuing.\n\n**Root or sudo access.** The procedure manipulates Docker volumes and system files; privileged access is mandatory.\n\n**Operational v1 instance.** Confirm the current version via the web interface (Settings → About). The migration assumes the instance starts and that its database is consistent — if it is already corrupted, restore a backup first.",{"type":34,"title":50,"body":51},"Mandatory backup before migration","The v1 → v2 migration transforms the SQLite schema irreversibly. Without a valid backup, a full rollback is impossible.\n\n**Identify the volume or data folder.** If you use Docker Compose with a named volume, the default name is `uptime-kuma_uptime-kuma-data`. Confirm with `docker volume ls | grep kuma`. If you use a bind mount, locate the path in your `docker-compose.yml` — typically `.\u002Fdata:\u002Fapp\u002Fdata`.\n\n**Stop the container before the backup.** A SQLite database backed up during active writes may be corrupted. Never use the `-v` flag when stopping: it would delete the volume and its contents.",{"type":53,"title":54,"steps":55},"steps","Backing up the data volume",[56,59,62],{"title":57,"body":58},"Stop Uptime Kuma","Stop the container without removing the volume:\n```bash\ndocker compose down\n```\nWait for the confirmation `Container uptime-kuma Stopped` before continuing.",{"title":60,"body":61},"Back up a named Docker volume","Use a busybox container to create a compressed archive of the 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```\nCheck the archive size with `ls -lh uptime-kuma-v1-backup.tar.gz`. An archive of only a few bytes indicates a mounting problem — fix it before continuing.",{"title":63,"body":64},"Back up a bind mount","If your data is in a host folder (example: `.\u002Fdata`):\n```bash\ntar czf uptime-kuma-v1-backup.tar.gz .\u002Fdata\n```\nKeep this archive off the server (object storage, remote server) before proceeding to the migration.",{"type":53,"title":66,"steps":67},"v1 → v2 migration: step-by-step procedure",[68,71,74,77,80,83],{"title":69,"body":70},"Update the image in docker-compose.yml","Open your `docker-compose.yml` and replace the image tag:\n```yaml\n# Before\nimage: louislam\u002Fuptime-kuma:1\n# After\nimage: louislam\u002Fuptime-kuma:2\n```\nIf you use the `latest` tag, prefer an explicit version tag like `louislam\u002Fuptime-kuma:2.5.0` to avoid regressions during future automatic upgrades.",{"title":72,"body":73},"Pull the new image","Download the v2 image before starting the service:\n```bash\ndocker pull louislam\u002Fuptime-kuma:2\n```\nVerify the image is present: `docker images | grep uptime-kuma`.",{"title":75,"body":76},"Start the v2 container","Launch the service. Docker Compose detects the image change and recreates the container:\n```bash\ndocker compose up -d\n```\nWait for the confirmation `Container uptime-kuma Started`.",{"title":78,"body":79},"Follow the database migration","On first start, Uptime Kuma migrates the SQLite schema to the v2 format. This can take from a few seconds to several tens of minutes depending on database size:\n```bash\ndocker compose logs -f uptime-kuma\n```\nDo not interrupt the container during this phase. Wait for a line confirming the end of the migration before continuing.",{"title":81,"body":82},"Check the healthcheck","Verify the container is in `healthy` state:\n```bash\ndocker compose ps\n```\nThe `Status` column must show `healthy`. If it stays on `starting` for more than two minutes after migration logs end, check the logs to identify the error.",{"title":84,"body":85},"Confirm the active version in the interface","Log in to the web interface. Go to **Settings → About** and verify the displayed version starts with `2.`. Confirm all your monitors are present and their statuses match the actual state of your services.",{"type":34,"title":87,"body":88},"Post-migration checks","A successful migration is not just a container that starts. Go through these points before considering the operation complete.\n\n**Monitors.** Open the dashboard and compare the monitor count with your v1 inventory. A missing monitor may indicate a partial migration issue — check logs at the `ERROR` or `WARN` level.\n\n**Notifications.** Manually trigger a notification test for each configured channel (email, Telegram, webhook). v2 applies strict Liquid template validation: a field containing non-conforming tags will be rejected. Use this opportunity to audit monitor names and remove any unexpected template content — this is the exact vector of CVE-2026-45618.\n\n**Status page.** If you expose a public status page, verify it responds correctly and lists the right services. The URL and slug are preserved after migration.\n\n**SSL certificates.** TLS probes restart their verification cycle after migration. A certificate close to expiry before the migration may trigger an alert immediately: verify the actual date before treating this as a regression.",{"type":90,"title":91,"body":92},"tip","Hardening the instance after migration","**Mandatory authentication.** In v2, authentication is enabled by default. Check in Settings → Security that passwordless access is disabled. On a freshly deployed instance with no account configured, the interface is publicly accessible during initial setup: create the admin account within the first minutes after the first start.\n\n**Dedicated subdomain behind a reverse proxy.** Do not expose Uptime Kuma on a direct port (`:3001`). Place it behind Nginx or Caddy on a dedicated subdomain (`status.your-domain.com`) with TLS. Close port 3001 at the firewall: `ufw deny 3001`.\n\n**Fail2ban or CrowdSec in front of the proxy.** Add a bruteforce detection rule on interface login attempts. CrowdSec has an `uptime-kuma` scenario in its Hub. See the article \u003Ca href=\"\u002Fblog\u002Fsecuriser-vps-crowdsec\">Securing your VPS with CrowdSec\u003C\u002Fa> for the full procedure.\n\n**Network isolation.** Place Uptime Kuma in a dedicated Docker network. It only needs to reach the targets it monitors — not your production databases or internal APIs.",{"type":34,"title":94,"body":95},"Troubleshooting: common errors","**Incompatible volume or corrupted database.** If logs show `SQLITE_ERROR: no such table` or `database disk image is malformed`, the mounted database is not a valid Uptime Kuma v1 database, or the backup was taken while the database was being written. Restore the archive, stop the container cleanly, and restart the procedure from the backup step.\n\n**Port 3001 already in use.** The error `address already in use :::3001` means a process already uses this port. Identify it with `ss -tlnp | grep 3001` and stop it, or change the port mapping in `docker-compose.yml` (for example `3002:3001`) and update your reverse proxy configuration.\n\n**Notification template rejected after migration.** If a notification channel shows a template error, LiquidJS 10.26.0 strict validation rejected a template that was tolerated in v1. Edit the template in Settings → Notifications and remove or fix the offending tags.\n\n**TLS certificate shown as expired.** TLS probes restart their cycle after migration. Verify the actual date with `echo | openssl s_client -connect your-domain.com:443 2>\u002Fdev\u002Fnull | openssl x509 -noout -dates` before treating this alert as an incident.\n\n**Container in a restart loop.** If migration fails and the policy is `restart: always`, Docker will restart the container indefinitely. Switch to `restart: no`, fix the issue identified in the logs, then restore the original policy.",{"type":34,"title":97,"body":98},"What this migration protects","Migrating to Uptime Kuma 2.x closes CVE-2026-45618 on a surface directly accessible from the administration interface. For an agency managing multiple clients' infrastructure from a shared instance, this surface is proportional to the number of accounts and monitors configured: each additional client widened the exposed perimeter.\n\nv2 also brings structural changes that reduce the long-term attack surface: rootless Docker image by default, actively maintained dependencies, and a 14-day delay mechanism before integrating new npm dependencies — to limit supply chain attacks, as documented in the article \u003Ca href=\"\u002Fblog\u002Fsecuriser-chaine-approvisionnement-npm-ci\">Securing the npm supply chain in CI\u003C\u002Fa>.\n\nManaging and securing multiple clients' infrastructure from a single centralized space, without bearing the risks of end-of-maintenance alone, is what the ServOrbit agency space enables.","One space to manage all your clients' infrastructure","The ServOrbit agency space centralizes domains, hosting and VPS for your entire portfolio. You manage the client relationship, we hold the infrastructure.","ServOrbit agency space","\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,"monitoring-your-vps-with-uptime-kuma",{"fr":108,"en":106,"ar":109},"superviser-vps-uptime-kuma","مراقبة-خادمك-الافتراضي-vps-باستخدام-uptime-kuma","Monitoring your VPS with Uptime Kuma","Deploy Uptime Kuma on your VPS to monitor your sites and services self-hosted, with alerts and a public status page.",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-observability",{"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,"securing-your-vps-with-crowdsec",{"fr":124,"en":122,"ar":125},"securiser-vps-crowdsec","تأمين-خادمك-الافتراضي-vps-باستخدام-crowdsec","Securing your VPS with CrowdSec","Deploy CrowdSec on your VPS to block attacks thanks to behavioral detection and a shared community blocklist.",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-bastion","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,"vps-monitoring-with-grafana-and-prometheus",{"fr":141,"en":139,"ar":142},"monitoring-vps-grafana-prometheus","مراقبة-الخادم-الافتراضي-vps-باستخدام-grafana-و-prometheus","VPS Monitoring with Grafana and Prometheus","Set up a Grafana + Prometheus stack on your VPS to collect, store and visualize your system and application metrics.","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",1787581008105]