Vikunja has cross-tenant IDOR in kanban move-task endpoint via unauthorized body task_id

3. The task is loaded and mutated with no authorization

updateTaskBucket (pkg/models/kanban_task_bucket.go:119):

task := &Task{ID: b.TaskID}
err = task.ReadOne(s, a)            // loads ANY task by ID — no permission check

Task.ReadOne (pkg/models/tasks.go:1967) calls GetTaskByIDSimple + addMoreInfoToTasks; it performs no authorization (authorization normally lives in the separate Task.CanRead, which this internal call path bypasses).

• Read: the fully populated victim task is assigned to b.Task (line 227) and returned by the Update handler in the response "task" field.

• Write: if the target bucket is the view's done bucket (view.DoneBucketID == b.BucketID && !task.Done, line 141), the handler sets task.Done = true and persists it to the victim's task row:

  _, err = s.Where("id = ?", task.ID).
      Cols("done", "due_date", "start_date", "end_date", "done_at").
      Update(task)
  

Proof of Concept

The attacker is any normal authenticated user. They first create their own kanban project/view/bucket (free for every user), then:

POST /api/v1/projects/{ATTACKER_PROJECT}/views/{ATTACKER_VIEW}/buckets/{ATTACKER_BUCKET}/tasks HTTP/1.1
Host: TARGET
Authorization: Bearer {ATTACKER_JWT}
Content-Type: application/json

{"task_id": {VICTIM_TASK_ID}}

The 200 response body contains the victim task in full under "task" — title, description, dates, assignees, labels, attachment list, reactions. Task IDs are a global sequential counter, so iterating task_id enumerates every task on the instance.

If ATTACKER_BUCKET is the done bucket of ATTACKER_VIEW, the same request also flips the victim task to done (done = true, done_at set).

Impact

Any authenticated low-privilege user can:

• Read any task on the instance by sequential ID, across every other user, project and organization — a full cross-tenant information disclosure of task titles, descriptions, assignees, labels and attachment metadata.
• Modify any task's done state, marking arbitrary victims' tasks done (or clearing it) and altering done_at.

Vikunja's permission model is built specifically to isolate projects between users; this endpoint defeats that isolation. It is the same impact and class that warranted CVEs for task relations, attachments and comments.

Suggested fix

In TaskBucket.CanUpdate, after the bucket/project check, also verify the caller's permission on the body-supplied task — mirroring the remediation already applied to task relations and attachments:

task := &Task{ID: b.TaskID}
canUpdateTask, err := task.CanUpdate(s, a)
if err != nil || !canUpdateTask {
    return false, err
}

(Use CanRead if moving a readable-but-not-writable task into a bucket is intended; CanUpdate is the safer default since the operation can change the task's done state.)

References

• CWE-639 Authorization Bypass Through User-Controlled Key
• CWE-284 Improper Access Control
• OWASP A01:2021 Broken Access Control
• CVE-2026-33676, CVE-2026-33678, CVE-2026-33313, CVE-2026-35598 — the same missing-authorization-on-task-child class, already remediated; this report is the un-remediated TaskBucket sibling.

Additional notes

• The v2 API is affected too. The same endpoint is exposed under /api/v2/..., and both versions route through the shared model TaskBucket.CanUpdate / updateTaskBucket in pkg/models/kanban_task_bucket.go. A model-level fix closes v1 and v2 simultaneously; the regression test should assert both.

• Two fix altitudes. The minimal fix checks the body-supplied task_id in TaskBucket.CanUpdate (task.CanUpdate/CanRead). A broader fix makes Task.ReadOne itself permission-aware, which also hardens other internal call paths that rely on it — higher blast radius, weigh accordingly.

• Side effects of the cross-tenant write confirmed across reports: flipping done rewrites done_at/due_date/start_date/end_date, inserts a task_buckets row, propagates done-state to other kanban views with a done bucket in the victim's project, and triggers updateDone rescheduling for repeating tasks.