Live › vulnerability › CVE-2026-68581
Go to dashboardVikunja 0.22.0 through 2.3.0 does not check whether a JWT belongs to a user or a link share, so a link-share ID can match a target user's numeric ID. An authenticated attacker can then list, create and delete that user's API tokens, including tokens with attacker-chosen scopes.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 19:13 UTC, 0h before NVD. All times on this page are UTC.
| Product | Ecosystem | Affected | Fixed in |
|---|
| code.vikunja.io/api | go | >= 0.22.0 | – |
0.22.0 and 2.3.0Upgrade code.vikunja.io/api to 2.4.0 or later.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
Vikunja versions 0.22.0 through 2.3.0 fail to validate the principal type in API token management. Because user IDs and link-share IDs are independent numeric sequences and both resolve through a generic web.Auth.GetID() interface, a link-share JWT whose numeric ID equals a target user's ID is treated as that user by the /api/v1/tokens endpoints. An authenticated attacker can obtain a target's numeric user ID via authenticated user search, then create link shares on an attacker-writable project until the link-share sequence reaches that value, and use the resulting link-share JWT to list, create, and delete the target user's API tokens (including issuing a new token with attacker-chosen scopes under the target's permissions). Fixed in version 2.4.0.
This page as .md · .json · in your agent: get_signal("CVE-2026-68581")
Go Vulnerability Database, CC-BY 4.0 · EPSS scores by FIRST, used with attribution · NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.