Summary
CVE-2026-49819 is a critical authentication bypass vulnerability in UpSnap, a self-hosted Wake-on-LAN web application built with SvelteKit, Go, and PocketBase. The flaw allows an unauthenticated, network-adjacent attacker to claim the initial superuser account on a fresh installation and obtain a long-lived JWT, which can subsequently be abused to achieve arbitrary command execution as root. The issue carries a CVSS v3.1 base score of 9.8 (Critical).
Technical details
- Root cause: The
POST /api/upsnap/init-superuserendpoint (handled bypb.HandlerInitSuperuser) is gated only by a check for whethertotalSuperusers > 0. On a freshly deployed or not-yet-configured instance, this condition is always false, so the endpoint performs no authentication or authorization check at all. - Trigger conditions: Any attacker with network access to the instance’s setup endpoint before a legitimate administrator completes initial configuration can register themselves as the first superuser and receive a valid, long-lived JWT.
- Attack vector: Network (AV:N), no privileges or user interaction required (PR:N/UI:N), low attack complexity (AC:L).
- Impact: Once authenticated as superuser, the attacker can manage devices in UpSnap, including the
wake_cmdfield, which is passed to a shell without proper sanitization. This chains the authentication bypass into full command injection, giving the attacker root-level remote code execution on the host running UpSnap.
Affected software
- UpSnap (seriousm4x/UpSnap) versions 4.4.1 through 5.3.5 (vulnerability introduced around December 29, 2024)
- Fixed in version 5.4.0 and later
Severity
- CVSS v3.1 Base Score: 9.8 (Critical)
- Vector:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Mitigation and recommended actions
- Immediate: Upgrade UpSnap to version 5.4.0 or later, which introduces an out-of-band setup token mechanism requiring the
UPSNAP_SETUP_TOKENenvironment variable and validation of theX-Setup-Tokenheader via constant-time comparison before the initial superuser can be created. - If patching is not immediately possible:
- Do not expose UpSnap’s setup/initial configuration process to untrusted networks; restrict access to the application (especially during initial deployment) to trusted, internal networks only.
- Complete initial superuser setup immediately upon deployment, before exposing the instance to any shared or public network segment.
- Where possible, use the
upsnap superuser upsertCLI command instead of the web-based setup flow, as it enforces local-only access rather than relying on the network-reachable setup endpoint. - As a general practice, UpSnap should not be exposed directly to the open internet, since device wake/shutdown commands are executed via shell (potentially as root).

