---
id: "CVE-2026-62967"
kind: "vulnerability"
aliases: ["CVE-2026-62967"]
title: "ZTNET: any logged-in user can lock out other accounts, including admins"
severity: "high"
cvss: 8.1
epss: null
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["package", "self-hosted", "zerotier", "ztnet"]
not_affected_if: ["single-user", "version-0.8.0-or-later"]
published_at: "2026-10-30T21:17:15+00:00"
first_seen_at: "2026-10-30T21:25:53+00:00"
updated_at: "2026-10-30T21:26:39+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-62967", "first_seen_at": "2026-10-30T21:25:53+00:00"}]
---

# ZTNET: any logged-in user can lock out other accounts, including admins

ZTNET's account-invalidation endpoint does not check that the caller owns the user ID it deactivates. Any authenticated low-privilege user can permanently disable another account, including an administrator's, and that account is then refused login.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Check the ZTNET version and confirm it is below `0.8.0`
- Look for `src/pages/api/auth/user/invalidateUser.ts` in the deployed code and see whether it compares `session.user.id` with the request `userId`

## Fix

- ZTNET: move to `0.8.0` or later

## Timeline

- 2026-10-30T21:25:53+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-62967

## From the sources

ZTNET is a ZeroTier web UI for private controllers with multiuser and organization support. Prior to 0.8.0, any authenticated low-privilege user can permanently deactivate another account, including an administrator, through `POST /api/auth/user/invalidateUser`. In `src/pages/api/auth/user/invalidateUser.ts`, `getServerSession` checks only that a session exists and does not compare `session.user.id` with the client-supplied `userId`. Supplying a victim's `userId` and a `deviceId` for which no matching pair exists in `UserDevice` makes the handler set the target account's `isActive` to false. Login is then refused by `src/server/auth.ts` with `account-expired`. An attacker needs only a normal authenticated account and the victim's user ID, which may be obtainable from member lists, UI responses, logs, or other application metadata. This can lock administrators out, disrupt organization management, and deny access to any targeted user. This issue is fixed in version 0.8.0.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_