CVE-2026-55065 in Vikunja
Summary
by MITRE • 08/28/2026
Vikunja is an open-source self-hosted task management platform. From 0.24.6 until 2.4.0, DELETE /api/v1/projects/:project/views/:view permits an authenticated user to supply a view identifier from another project while authorizing only against an attacker-controlled project identifier. ProjectView.CanDelete in pkg/models/project_view_permissions.go does not establish that the view belongs to the path project, and ProjectView.Delete in pkg/models/project_view.go continues after the scoped project_views delete affects no rows. Its subsequent deletes select task_buckets and task_positions only by project_view_id, allowing cross-tenant destruction of Kanban assignments and ordering while leaving the victim view and tasks intact. This issue is fixed in version 2.4.0.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/28/2026
Vikunja serves as an open-source self-hosted platform for managing tasks and projects, relying on a RESTful API to handle client requests. A critical security flaw was identified within the application's project view deletion logic between versions 0.24.6 and 2.4.0. The vulnerability resides in the DELETE /api/v1/projects/:project/views/:view endpoint, which is designed to allow authenticated users to remove specific views associated with a given project. However, the implementation fails to enforce proper authorization boundaries when processing this request. Specifically, while the application checks permissions against the project identifier provided in the URL path, it does not verify that the view identifier supplied by the user actually belongs to that authorized project. This discrepancy creates an opportunity for authenticated users to manipulate the deletion process across different projects within their access scope or potentially escalate privileges if other authorization layers are similarly flawed.
The technical root cause of this vulnerability is located in the backend logic handling project view permissions and deletions. In the file pkg/models/project_view_permissions.go, the function ProjectView.CanDelete performs an authorization check but does not establish a strict linkage between the view being deleted and the project specified in the request path. Consequently, when the deletion process proceeds to pkg/models/project_view.go, the ProjectView.Delete method executes a database operation scoped to delete views from the attacker-controlled project. If this initial scoped delete affects zero rows because the target view does not belong to that project, the logic continues rather than aborting. The subsequent operations then proceed to delete associated task buckets and task positions based solely on the provided project_view_id, without re-validating ownership against a different or correct project context. This lack of cross-reference validation allows an attacker to specify any valid view identifier they can access, leading to unintended data destruction in unrelated contexts if the system architecture permits such ambiguity.
The operational impact of this vulnerability is significant for multi-tenant environments or users managing multiple projects with distinct Kanban boards and task structures. An authenticated user can exploit this flaw to destroy critical organizational data by deleting task buckets and reordering task positions associated with a victim view, even though the primary view object itself remains intact in the database. This results in the corruption of workflow states, loss of visual board configurations, and disruption of task ordering for other users or projects that rely on those specific structural elements. While the core tasks are not deleted, their association with buckets and positions is severed, leading to data inconsistency and potential functional breakage within the application's user interface. This represents a severe integrity violation where an actor can cause denial of service through data corruption without necessarily gaining unauthorized access to read sensitive information directly from the affected records.
This vulnerability aligns with CWE-602, Client-Side Enforcement of Server-Side Access Control, as the system relies on client-supplied identifiers for critical authorization checks rather than strictly enforcing server-side ownership verification during every step of the deletion process. It also relates to CWE-918, Improper Control of Dynamically-Managed Code Resources, due to the execution of database operations based on insufficiently validated inputs that lead to unintended side effects in data integrity. From a threat modeling perspective using MITRE ATT&CK, this behavior is consistent with techniques involving resource manipulation and potential privilege escalation through improper access control mechanisms, specifically falling under Tactic TA0004 Impact or TA0005 Defense Evasion depending on the attacker's ultimate goal of obscuring their actions by corrupting data structures.
To mitigate this vulnerability, organizations running Vikunja must upgrade to version 2.4.0 or later, where the developers have addressed these authorization checks and ensured that view deletions are strictly bound to the correct project context. For environments unable to patch immediately due to dependency constraints, implementing a Web Application Firewall rule to monitor for anomalous deletion patterns across different projects may provide limited protection, though this is not a substitute for fixing the underlying code logic. Administrators should also audit their access control policies to ensure that no other endpoints suffer from similar cross-resource authorization flaws. Regular security audits and static analysis of permission handling functions are recommended to prevent recurrence of such issues in future development cycles.