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}/tasks accepts a body supplied task_id but TaskBucket.CanUpdate in pkg/models/kanban_task_bucket.go authorizes only the project, view, and bucket from the URL. updateTaskBucket then calls Task.ReadOne without a separate task permission check, returns the victim task contents, and can update the task done state when the attacker chooses a done bucket. Because task identifiers are global sequential values, an authenticated user can enumerate cross-tenant tasks and modify their completion metadata through both the v1 and v2 routes that share this model. This issue is fixed in version 2.4.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.1",
  "pubDate": "2026-08-28T20:18:23.897Z",
  "pubdate": "2026-08-28T20:18:23.897Z",
  "executiveSummary": "Vikunja versions prior to 2.4.0 contain a critical Insecure Direct Object Reference (IDOR) vulnerability resulting from insufficient authorization controls during task management operations.\nThe vulnerability allows an authenticated attacker to bypass cross-tenant security boundaries by manipulating task identifiers within API requests.\nBecause the application utilizes global sequential identifiers for tasks, an attacker can enumerate tasks belonging to other users or organizations and gain unauthorized access to task data.\nBeyond data disclosure, the flaw permits the unauthorized modification of a task's 'done' state by moving it into specific buckets.\nThis represents a significant risk to data confidentiality and integrity within multi-tenant deployments, as it enables unauthorized information disclosure and state manipulation across restricted project boundaries.\nExploitation requires the attacker to hold an authenticated session, though they do not require administrative privileges within the victim's tenant to perform these actions.",
  "technicalDetails": "The root cause of this vulnerability lies in the authorization logic implemented in pkg/models/kanban_task_bucket.go within the TaskBucket.CanUpdate function. While the application properly validates access rights for the project, view, and bucket parameters derived from the URL path, it fails to perform an independent authorization check against the task_id provided in the request body.\nSpecifically, the POST /api/v1/projects/{project}/views/{view}/buckets/{bucket}/tasks endpoint accepts a user-supplied task_id. Upon receiving this payload, the updateTaskBucket function invokes Task.ReadOne to retrieve the task object. Because Task.ReadOne is executed without verifying that the authenticated user possesses the necessary permissions to access or modify the specified task, the application returns the contents of the target task to the requester regardless of the task's actual ownership or visibility constraints.\nThe exploitation flow proceeds as follows: First, an attacker identifies that task identifiers are global sequential integers, which are easily guessable. Second, the attacker constructs a malicious POST request targeting the /api/v1/projects/{project}/views/{view}/buckets/{bucket}/tasks route (or the corresponding v2 route, which shares the same underlying model). By injecting a target task_id belonging to a different tenant, the attacker coerces the application into processing the unauthorized task.\nIf the attacker selects a bucket designated as a 'done' state, the application updates the completion metadata of the victim's task. Consequently, an attacker can enumerate cross-tenant tasks to leak sensitive information or force state changes on arbitrary tasks within the platform.\nThe lack of a validation layer ensuring that the requested task_id is logically associated with the authorized bucket or project creates a bypass of the intended multi-tenant isolation. This vulnerability affects both v1 and v2 API versions, as they utilize shared model logic that fails to enforce strict object-level access controls. Successful exploitation results in the exposure of task metadata and unauthorized modification of the task's lifecycle status."
}