CVE-2026-68581 in vikunja
Summary
by MITRE • 08/02/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/02/2026
This vulnerability exists within Vikunja's authentication and authorization mechanisms, specifically in how the system handles token management for different principal types. The flaw stems from inadequate type validation during API token operations, creating a critical security gap that allows privilege escalation through numeric ID collision attacks. The root cause lies in the system's failure to properly distinguish between user IDs and link-share IDs within the generic web.Auth.GetID() interface, which processes both types through identical pathways without proper type checking.
The technical implementation of this vulnerability exploits the independent numeric sequences used for user identification and link-share identification within the application's database schema. When a link-share JWT contains a numeric ID that matches a legitimate user's ID, the system incorrectly treats the link-share as representing that user due to the lack of principal type validation in the authentication flow. This design flaw creates a scenario where an attacker can manipulate the sequence generation process to generate link-shares with IDs that collide with existing user IDs.
The operational impact of this vulnerability is severe and multifaceted, allowing authenticated attackers to perform unauthorized actions against target users' API tokens. An attacker begins by obtaining a target user's numeric ID through legitimate authenticated user search functionality, then systematically creates link shares on projects they can write to until reaching the target's ID value. Once this collision occurs, the attacker can leverage the resulting link-share JWT to execute full CRUD operations on the target user's API tokens, including listing existing tokens, creating new tokens with arbitrary scopes, and deleting tokens entirely. This effectively grants the attacker complete control over the target user's API access permissions.
The vulnerability demonstrates characteristics consistent with CWE-284 (Improper Access Control) and CWE-345 (Insufficient Verification of Data Authenticity), as it allows unauthorized privilege escalation through improper validation of principal types in authentication contexts. From an ATT&CK perspective, this maps to T1078 (Valid Accounts) and T1566 (Phishing), since the attack exploits legitimate authentication mechanisms to gain elevated privileges without requiring credential compromise. The attack vector requires only authenticated access to the system, making it particularly dangerous as it can be executed by any user with valid credentials.
Mitigation strategies should focus on implementing proper principal type validation within the authentication flow, ensuring that the web.Auth.GetID() interface enforces strict type checking before processing numeric identifiers. Security patches must separate user ID and link-share ID sequences with explicit type discrimination mechanisms, preventing numeric collisions from occurring in the first place. Organizations should also implement comprehensive logging of token management operations to detect unauthorized access attempts, while applying the latest version 2.4.0 or later which contains the necessary fixes for this vulnerability. Additionally, regular security assessments should verify that similar type confusion vulnerabilities do not exist in other parts of the authentication and authorization infrastructure.
This vulnerability represents a classic case of insufficient input validation combined with improper access control enforcement, highlighting the critical importance of maintaining clear type boundaries within authentication systems. The fix implemented in version 2.4.0 demonstrates the necessity of proper principal type discrimination in API token management systems, where failure to validate identity types can result in complete authorization bypass scenarios. Organizations should conduct thorough audits of their own authentication mechanisms to identify similar type confusion vulnerabilities that could enable similar privilege escalation attacks.