Description

Vikunja is an open-source self-hosted task management platform. Prior to 2.4.0, POST /api/v1/projects/{project}/views/{view}/buckets/{bucket} allows the request body project_view_id value to be mass assigned by Bucket.Update in pkg/models/kanban.go. The permission check validates that the bucket currently belongs to the URL project and view but does not validate the body selected destination view, allowing any authenticated user to relocate an attacker-owned bucket into another tenant’s Kanban view. The injected bucket retains attacker-controlled content and ownership, enabling cross-tenant defacement. This issue is fixed in version 2.4.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.0",
  "pubDate": "2026-08-28T20:18:24.037Z",
  "pubdate": "2026-08-28T20:18:24.037Z",
  "executiveSummary": "Vikunja versions prior to 2.4.0 are susceptible to a mass assignment vulnerability, specifically categorized as an Improper Authorization flaw. The vulnerability allows an authenticated user to perform unauthorized cross-tenant operations by manipulating the 'project_view_id' parameter within the 'POST /api/v1/projects/{project}/views/{view}/buckets/{bucket}' endpoint.\nThe vulnerability resides in the 'Bucket.Update' function located in 'pkg/models/kanban.go'. Because the application fails to validate the target 'project_view_id' against the current user's authorized scope, an attacker can move a bucket they control into a victim's Kanban view. This action results in unauthorized data injection and potential cross-tenant defacement, as the relocated bucket retains its original content and ownership attributes while appearing within the victim's workspace.\nExploitation requires the attacker to be an authenticated user within the Vikunja instance. There are no special privilege requirements beyond the ability to manage their own buckets. This vulnerability poses a significant risk to data integrity and organizational isolation in multi-tenant self-hosted environments.",
  "technicalDetails": "The vulnerability is primarily a server-side mass assignment issue stemming from the handling of input parameters within the 'Bucket.Update' model function in 'pkg/models/kanban.go'. In the affected versions of Vikunja, the API endpoint 'POST /api/v1/projects/{project}/views/{view}/buckets/{bucket}' accepts a JSON payload that is bound directly to the database model without sufficient filtering of restricted fields.\nThe root cause is an incomplete authorization check. While the system correctly validates that the bucket currently being updated belongs to the source project and view provided in the URL parameters, it performs no secondary validation on the 'project_view_id' supplied within the request body. This allows an attacker to specify an arbitrary destination 'project_view_id' that resides outside of their authorized project or tenant scope.\nThe attack flow proceeds as follows: First, an authenticated attacker identifies a valid target project/view ID belonging to another tenant or a restricted project. Second, the attacker crafts a POST request to their own bucket resource endpoint. Third, the attacker includes the 'project_view_id' of the target victim's view in the request body. When the 'Bucket.Update' logic executes, it processes the 'project_view_id' field, effectively re-associating the attacker-controlled bucket with the destination view.\nBecause the 'Bucket.Update' function does not enforce boundaries during the re-assignment of the 'project_view_id' attribute, the bucket is successfully moved into the victim's Kanban interface. The injected bucket retains all original attacker-controlled content, including task descriptions, metadata, and assigned user identifiers. This persistence allows the attacker to achieve cross-tenant defacement or unauthorized content insertion within the victim's board.\nThis vulnerability effectively bypasses the multi-tenancy logical isolation enforced by the application's permission model. Since the system treats the bucket's content as trusted data originating from the owner, the content is rendered in the victim's view without further validation, leading to potential data exposure or visual disruption of the victim's workflow."
}