CVE-2026-123503 in Vikunja
Summary
by MITRE • 11/08/2026
Vikunja before 2.7.1 contains an improper authorization vulnerability in canDoBucket that allows users with project write access to delete buckets via a mismatched view ID. Attackers can request deletion through another view's bucket endpoint to bypass the last-bucket rule, leaving dangling default/done bucket references and inconsistent task buckets.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 11/08/2026
The identified security flaw resides within the Vikunja application prior to version 2.7.1, specifically affecting the authorization logic governing bucket management operations. This vulnerability is classified as an improper access control issue where the system fails to properly validate whether a user has sufficient privileges for the specific resource they are attempting to modify or delete. The core of the problem lies in the canDoBucket function, which is responsible for checking permissions before executing actions on buckets within projects. While users with project write access generally have broad capabilities, the implementation contains a logical error that allows these users to bypass intended restrictions through ID manipulation.
The technical mechanism of this exploit involves mismatching view identifiers during deletion requests. Vikunja organizes tasks into buckets which are often associated with specific views or contexts within a project structure. The application enforces rules designed to prevent the accidental deletion of critical default structures, such as the Done bucket or other system-maintained containers that serve as fallbacks for unassigned tasks. However, by crafting an HTTP request that targets the bucket endpoint using a view ID from a different context than the one associated with the target bucket, attackers can trick the authorization middleware into granting permission based on the mismatched but valid write access of their current session. This bypasses the last-bucket rule and other integrity checks designed to preserve essential data structures.
The operational impact of this vulnerability is significant for data integrity within Vikunja instances. Successful exploitation allows an authenticated user with project write permissions to delete buckets that should be protected, including default or done buckets. When these critical buckets are deleted, the system loses its ability to properly categorize tasks that do not belong to any other specific bucket. This results in dangling references where task records point to non-existent bucket IDs, leading to database inconsistencies and potential application errors when users attempt to view or manage their task lists. The loss of default containers disrupts the workflow logic for all project members, as new tasks may fail to be assigned correctly or become inaccessible through standard interface views.
From a classification perspective, this vulnerability aligns with CWE-269, which denotes Improper Privilege Control, and specifically relates to authorization bypasses where access controls are not enforced consistently across different resource identifiers. In the context of the MITRE ATT&CK framework, this behavior corresponds to techniques involving unauthorized access or modification of application data by exploiting flawed logic in permission checks rather than breaking cryptographic protections or injecting code. The attack vector is primarily remote and requires authentication, placing it within the scope of authenticated attacker scenarios where insider threats or compromised credentials are leveraged for lateral movement or data destruction within a specific project context.
To mitigate this vulnerability, organizations running Vikunja must immediately upgrade to version 2.7.1 or later, which contains patches that correct the authorization logic in the canDoBucket function. The fix ensures that permission checks strictly validate the relationship between the requesting view ID and the target bucket ID, preventing deletion of protected buckets regardless of how the request is constructed. Until an upgrade is performed, administrators should monitor for unusual patterns of bucket deletions within projects, particularly those involving default or system-managed containers. Implementing strict input validation on client-side applications to prevent mismatched IDs from being sent in API requests can also serve as a defensive layer, although server-side enforcement remains the primary and necessary control. Regular audits of database integrity regarding task-to-bucket mappings are recommended to detect any residual inconsistencies resulting from prior exploitation attempts.