Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.1",
  "pubDate": "2026-08-28T20:18:23.757Z",
  "pubdate": "2026-08-28T20:18:23.757Z",
  "executiveSummary": "Vikunja versions 0.24.6 through 2.4.0 contain an Insecure Direct Object Reference (IDOR) vulnerability located within the view deletion API.\nThe vulnerability allows an authenticated attacker to perform unauthorized deletion of Kanban assignments and task ordering configurations associated with views belonging to other projects.\nThis occurs because the application fails to validate the relationship between the requested view identifier and the project identifier provided in the URI path.\nThe scope of impact is cross-tenant data corruption/destruction, where an attacker can target arbitrary views by manipulating request parameters.\nExploitation requires valid user authentication within the platform. The vulnerability does not result in unauthorized task deletion, but effectively disrupts the organization and metadata of victim projects, leading to a significant loss of data integrity in Kanban boards.",
  "technicalDetails": "The root cause of this vulnerability lies in insufficient authorization logic within the 'DELETE /api/v1/projects/:project/views/:view' endpoint. The implementation relies on the function 'ProjectView.CanDelete' located in 'pkg/models/project_view_permissions.go', which verifies permissions based on the attacker-controlled project identifier but fails to confirm that the requested view identifier resides within that specific project scope.\nWhen a deletion request is initiated, the application logic proceeds to 'ProjectView.Delete' in 'pkg/models/project_view.go'. Critically, if the scoped project_views query returns zero rows—indicating the view does not belong to the project specified in the URI—the function does not abort the operation.\nInstead, the execution flow continues, executing secondary database operations that delete 'task_buckets' and 'task_positions' based solely on the 'project_view_id'. Because these secondary operations are not scoped by the project ID, an attacker can supply the view ID of a target project while providing their own project ID as the context for the initial authorization check. This bypasses the intended security controls.\nThe step-by-step attack flow is as follows: 1) An authenticated user identifies a target 'project_view_id' belonging to a different project. 2) The user sends a DELETE request to their own project's path ('/api/v1/projects/attacker-project/views/victim-view-id'). 3) The 'CanDelete' check passes because the user has rights to the 'attacker-project'. 4) The 'ProjectView.Delete' function executes; the initial scoped deletion of the view fails (as intended), but the subsequent delete statements targeting 'task_buckets' and 'task_positions' execute using the 'victim-view-id'.\nThe resulting impact is the destruction of Kanban column configurations and task positioning data for the victim view. While the view entity itself and the individual tasks remain intact, the visual organization and task mapping are effectively deleted, resulting in service disruption and metadata loss for the victimized project."
}