UpSnap
CVE-2026-49819
CRITICAL
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Fresh installs expose an unauthenticated setup endpoint (PR:N/AC:L/UI:N) chaining to root shell (C/I/A:H); AV:N kept per advisory's publicly-reachable framing despite 'network-adjacent' wording, which would justify AV:A.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
3DescriptionCVE.org
UpSnap is a wake on lan web app. Versions 4.4.1 through 5.3.5 are vulnerable to a missing-authentication / privilege-escalation chain in pb.HandlerInitSuperuser (backend/pb/handlers.go:249), reachable as POST /api/upsnap/init-superuser. The vulnerable code lacks any authentication, setup token, IP allow-list, or rate limit and is gated only by a totalSuperusers > 0 count check - a condition that is false on every fresh install - allowing an unauthenticated network-adjacent attacker to register the initial superuser account, receive a long-lived JWT, and pivot to root remote code execution at backend/networking/wake.go:43 (exec.CommandContext(ctx, "/bin/sh", "-c", wake_cmd)). Version 5.4.0 fixes the issue.
AnalysisAI
Unauthenticated superuser takeover in UpSnap 4.4.1 through 5.3.5 lets a network attacker seize an un-provisioned instance by calling POST /api/upsnap/init-superuser, which is guarded only by a totalSuperusers > 0 check that is always false on a fresh install. After registering the first admin and obtaining a long-lived JWT, the attacker abuses UpSnap's device wake/shutdown command feature to reach exec.CommandContext("/bin/sh","-c", ...) and execute shell commands as the server user (root in typical container deployments). No KEV listing and no public exploit identified at time of analysis; the fix is in 5.4.0.
Technical ContextAI
UpSnap is a self-hosted Wake-on-LAN web application built on the PocketBase (Go) framework, identified by CPE cpe:2.3:a:seriousm4x:upsnap. The flaw is a missing-authentication design gap in pb.HandlerInitSuperuser (backend/pb/handlers.go:249): the initial-setup endpoint has no authentication, setup token, IP allow-list, or rate limit, and relies solely on a superuser-count gate to decide whether setup is 'done'. The RCE primitive it chains into is a classic CWE-78 OS Command Injection: UpSnap builds device wake/shutdown commands with user-controlled {{ DEVICE_IP }}/{{ DEVICE_MAC }} placeholders and runs the result through /bin/sh -c at backend/networking/wake.go:43, so any authenticated admin (which the attacker becomes) can inject arbitrary shell.
RemediationAI
Vendor-released patch: 5.4.0 - upgrade to UpSnap 5.4.0 or later, which removes the in-app setup wizard and moves first-superuser creation out-of-band to a one-time PocketBase setup link printed in the server console logs, so only someone with server-log access can complete provisioning (per advisory GHSA-w4jr-728f-5jhq, https://github.com/seriousm4x/UpSnap/security/advisories/GHSA-w4jr-728f-5jhq). If you cannot upgrade immediately, ensure initial setup has been completed by a legitimate admin so totalSuperusers is non-zero (this closes the init-superuser path), and until then do not expose the instance to untrusted networks - block external access to the UpSnap port at the firewall/reverse proxy and restrict /api/upsnap/init-superuser to trusted admin IPs; the trade-off is that this only helps before an attacker has already claimed the superuser account, so verify no rogue superuser exists. Because the RCE primitive is admin-controlled shell command templating, also review device wake/shutdown commands for unexpected shell metacharacters after upgrading.
Same weakness CWE-78 – OS Command Injection
View allShare
External POC / Exploit Code
Leaving vuln.today