GHSA-5pg6-m483-7vrg

## Summary

The kanban endpoint `POST /api/v1/projects/{project}/views/{view}/buckets/{bucket}/tasks` moves a task into a bucket. The task is identified by `task_id` in the **request body**. The endpoint's authorization check (`TaskBucket.CanUpdate`) only verifies that the caller may update the *project/view/bucket named in the URL* — it never checks any permission on `task_id`.

Any authenticated user can therefore supply another user's task ID (task IDs are a global, sequential integer space) against a kanban bucket in their **own** project. The server loads that victim task with no authorization check, returns its full contents in the response, and — when the target bucket is a "done" bucket — writes to the victim task's row.

This is the same vulnerability class Vikunja has already remediated for task relations (CVE-2026-33676), task attachments (CVE-2026-33678), task comments (CVE-2026-33313) and CalDAV task read (CVE-2026-35598). `TaskBucket` is the task-child operation that was missed.

---

## Root cause

### 1. `task_id` is body-controlled and never permission-checked

`pkg/models/kanban_task_bucket.go:32`:

type TaskBucket struct { BucketID int64 `... json:"bucket_id" param:"bucket"` TaskID int64 `... json:"task_id"` // body-bound only — no param tag ProjectViewID int64 `... json:"project_view_id" param:"view"` ProjectID int64 `xorm:"-" json:"-" param:"project"` ... }

The web handler `UpdateWeb` (`pkg/web/handler/update.go`) populates the struct via `ctx.Bind`, which binds both URL path params (`param:` tags) **and** the JSON body. `BucketID`, `ProjectViewID`, `ProjectID` come from the trusted URL; `TaskID` comes entirely from the attacker-controlled body.

### 2. `CanUpdate` authorizes the URL, not the task

`pkg/models/kanban_task_bucket.go:52`:

func (b *TaskBucket) CanUpdate(s *xorm.Session, a web.Auth) (bool, error) { bucket := Bucket{ID: b.BucketID, ProjectID: b.ProjectID, ProjectViewID: b.ProjectViewID} return bucket.canDoBucket(s, a) }

`canDoBucket` (`pkg/models/kanban_permissions.go:46`) resolves the bucket/view and ends in `Project{ID: pv.ProjectID}.CanUpdate(s, a)` — a permission check on the **project from the URL**. `b.TaskID` is never referenced. The attacker owns that project, so the check passes.

### 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.