ZTNET CVE-2026-62967

Requires (1) a valid authenticated ZTNET account of any privilege level - the attacker uses their own normal session, so deployments that allow open self-registration are directly exposed while closed/admin-approved registration raises the bar; and (2) knowledge of the target's userId, which the advisory notes can be gleaned from member lists, UI responses, logs, or other application metadata. The specific trigger is supplying the victim's userId together with a deviceId that has no matching row in the UserDevice table, which forces the handler into the branch that sets the target's isActive=false. Limiting factors: affects only ZTNET <= 0.7.18 (fixed in 0.8.0); no confidentiality exposure and no code execution - impact is limited to deactivating accounts/denial of login; no user interaction is required from the victim.

Signals mostly align toward a genuine but bounded priority. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N) describes a network-reachable, low-complexity flaw requiring a low-privilege authenticated account - matching CWE-862 (missing authorization): the handler calls getServerSession/getSession to confirm a session exists but never compares session.user.id to the client-supplied userId. The real-world impact is denial of service / account takeover-level lockout, not confidentiality loss (C:N), so despite the 8.1 score this is a DoS/integrity issue rather than code execution or data theft. There is NO CISA KEV entry and NO EPSS score in the supplied data, so exploitation-in-the-wild and statistical exploitation probability are both unknown and must not be assumed; however a detailed public proof-of-concept exists in the GHSA advisory and was confirmed dynamically on v0.7.18, so the barrier to exploitation is low for anyone who can obtain an account. No SSVC exploitation/automatable/technical-impact decision tree was provided - only the vuln.today 'this_week' priority label, which is consistent with 'patch within the week' rather than emergency. Net: for any multi-user or organization ZTNET instance where untrusted users can register, this is a real near-term priority because any normal user can permanently lock out administrators; for single-admin or closed-registration deployments the practical risk is much lower because the attacker must first hold a valid account.

A low-privilege user who already holds (or can self-register) a normal ZTNET account logs in to obtain a session cookie, learns an administrator's user ID from a member list or UI response, and sends a single POST to /api/auth/user/invalidateUser with the victim's userId and a random non-existent deviceId. Because the (userId, deviceId) pair is not found in UserDevice, the handler sets the admin's isActive to false, and that admin can no longer log in (rejected as account-expired). A working step-by-step PoC is published in the GHSA advisory and was confirmed dynamically against v0.7.18; the network vector and low attack complexity make the request trivial to replay.