TL;DR: UpSnap 4.4.1 through 5.3.5 exposes POST /api/upsnap/init-superuser with no authentication. On a fresh install, an attacker on the network can claim the initial superuser account, receive a long-lived JWT, and pivot to root remote code execution through the wake command handler. Upgrade to 5.4.0 or later.

What happened

The bug lives in pb.HandlerInitSuperuser at backend/pb/handlers.go:249. The handler that registers the first superuser account checks only whether a superuser already exists (totalSuperusers > 0). There is no authentication, no setup token, no IP allow-list, and no rate limit on the route.

On a fresh install that condition is false, so the endpoint is open to anyone who can reach the dashboard. An attacker sends POST /api/upsnap/init-superuser, registers themselves as the initial superuser, and gets back a long-lived JWT.

That account is not just an admin login. UpSnap lets the superuser configure per-device wake and shutdown commands that run through /bin/sh -c at backend/networking/wake.go:43. The superuser puts their own command in the wake_cmd field, and UpSnap runs it with exec.CommandContext(ctx, "/bin/sh", "-c", wake_cmd). The command executes with the privileges of the process running UpSnap, which the advisory describes as root. Unauthenticated account takeover becomes root code execution in two steps.

Who is affected

UpSnap is a self-hosted Wake-on-LAN web dashboard built with SvelteKit, Go, and PocketBase. Homelab users and small IT teams run it as a Docker container (ghcr.io/seriousm4x/upsnap or seriousm4x/upsnap on Docker Hub) to wake, ping, and shut down machines on their LAN from a browser. The project has around 5,800 GitHub stars and ships Docker images for amd64, arm64, arm/v7, and arm/v6.

Versions 4.4.1 through 5.3.5 are affected. The weakness is most dangerous on a fresh deployment: the window stays open until a legitimate administrator creates the first superuser, and if the admin never does, the install stays claimable indefinitely.

What to do

Upgrade to 5.4.0 or later. The maintainer patched the handler in 5.4.0, and 5.4.3 is the current release.

docker pull seriousm4x/upsnap:latest

If you use a pinned tag, move to 5.4.3. After upgrading, check the superuser list for accounts you did not create, and audit the wake and shutdown commands on every device for anything you did not configure.

Do not expose the dashboard port to the internet. UpSnap is meant for a trusted LAN, and this chain is reachable by any device that can reach the port, not just a logged-in user.

Why it matters

This is an unauthenticated path to root on the host. A device on the same network can own the machine running UpSnap without credentials, and because the container runs as root in the default Docker configuration, the wake command handler gives the attacker a shell with full control of the host.

NVD has not assigned a CVSS score yet. The missing-authentication and command-injection chain is critical in practice, and UpSnap instances that were deployed and left with their default setup are the ones to check first.

References

• NVD: CVE-2026-49819
• hol.org: CVE-2026-49819
• github.com/seriousm4x/UpSnap