Vikunja versions 0.22.0 through 2.3.0 lack validation for the principal type in API token management. Because the system treats user IDs and link‑share IDs as identical numeric sequences, a link‑share JWT whose numeric ID matches a target user's ID is recognized as that user. An attacker with the ability to create link shares can therefore generate an ID collision, obtain a token that appears to belong to the target user, and subsequently list, create, or delete that user’s API tokens, including issuing new tokens with the attacker’s chosen scopes under the target’s permissions. This flaw is a missing access control weakness identified as CWE‑863.

Instances of Vikunja produced by go‑vikunja that run any version between 0.22.0 and 2.3.0 are vulnerable, regardless of deployment size or hosting environment.

The CVSS score of 8.6 classifies this flaw as high severity, indicating that exploitation can grant an attacker the full privileges of another user. No EPSS value is available, but the attack only requires a legitimate account with permission to search users and create link shares—common functions for many users—so the exploit is realistic. The vulnerability is not listed in the CISA KEV catalog, yet its high impact and the fact that it does not need remote code execution make it a serious risk for any affected deployment.