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.
Fix
Nothing published yet: no patch, vendor advisory or mitigation reference on NVD, no vendor advisory in the News for this CVE, not in CISA's KEV, no fixed package version. BaselineWatch does not guess at one.
Change history 1
- First seenCVSS 8.6NVD modified 2026-10-23 22:10
Affected (CPE criteria) 0
NVD has not attached CPE configurations yet.
References 5
- https://github.com/go-vikunja/vikunja/commit/95b7e673fb5ee407498fa4b13e8b4c57847a4a0b
- https://github.com/go-vikunja/vikunja/commit/e6b25bd57b537ef9a72b5acdadf446ca5ef77bfa
- https://github.com/go-vikunja/vikunja/security/advisories/GHSA-vvcv-vpph-h844
- https://www.vulncheck.com/advisories/vikunja-through-authentication-bypass-via-principal-id-collision
- https://github.com/go-vikunja/vikunja/security/advisories/GHSA-vvcv-vpph-h844