Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-08-13T00:17:32.747Z",
  "pubdate": "2026-08-13T00:17:32.747Z",
  "executiveSummary": "UpSnap versions 4.4.1 through 5.3.5 suffer from a missing-authentication and privilege-escalation vulnerability that enables unauthenticated, network-adjacent attackers to achieve remote code execution as root. The flaw resides in the initial superuser setup handler, which fails to enforce authentication, setup tokens, rate limiting, or IP restrictions. Instead, it relies solely on a total superuser count check that evaluates to false on fresh installations. By successfully interacting with the setup endpoint, an attacker can register an arbitrary superuser account, acquire a long-lived JSON Web Token (JWT), and subsequently leverage authenticated administrative functionality to execute arbitrary shell commands on the underlying host system. This vulnerability poses an immediate and critical risk to confidentiality, integrity, and availability, effectively granting full system compromise to unauthorized entities capable of reaching the web application interface.",
  "technicalDetails": "The vulnerability is rooted in the initialization handler function pb.HandlerInitSuperuser, located at backend/pb/handlers.go:249 and exposed via the HTTP route POST /api/upsnap/init-superuser. The root cause of the flaw is the complete absence of robust access controls. The handler lacks authentication requirements, setup validation tokens, IP allow-lists, and rate-limiting mechanisms. The only gatekeeping logic implemented is a check ensuring that totalSuperusers > 0, which is false on every fresh installation of UpSnap.\nBecause this condition evaluates to false prior to the creation of the initial administrator, an unauthenticated network-adjacent attacker can issue an HTTP POST request to POST /api/upsnap/init-superuser to register a new superuser account with arbitrary credentials. Upon successful execution of this request, the application creates the administrative account and returns a long-lived JWT to the caller, effectively granting full administrative privileges.\nArmed with the newly acquired long-lived JWT, the attacker can authenticate to the web application and pivot to remote code execution. Specifically, the attack chain leads to backend/networking/wake.go:43, where the application invokes exec.CommandContext(ctx, \"/bin/sh\", \"-c\", wake_cmd). Because the execution context passes attacker-controlled or insufficiently sanitized parameters into a system shell wrapper, the execution of arbitrary commands results in root-level remote code execution on the host operating system.\nThe affected product is UpSnap, specifically versions 4.4.1 through 5.3.5. Exploitation requires network adjacency to the target web application interface, and the target must not have previously initialized its superuser account, rendering fresh or uninitialized instances critically exposed."
}