GHSA-569v-q83c-3j3g

Описание

Summary

POST /api/v1/projects/{project}/views/{view}/buckets/{bucket} mass-assigns the request body's project_view_id onto the bucket row. The permission check only verifies that the URL-supplied bucket already belongs to the URL-supplied (project, view) pair; the body's project_view_id is never validated. Any signed-in user can therefore take one of their own buckets and graft it into any other tenant's kanban view, with attacker-controlled title and the attacker's account as created_by.

This vulnerability was found using an LLM, and manually verified against latest (2.3.0).

Vulnerable code

pkg/models/kanban.go (lines 348-359):

Bucket.CanUpdate (canDoBucket) only validates that the URL-supplied {bucket} belongs to the URL-supplied {project}/{view}. The body's project_view_id reaches Update unchecked and is written through.

Proof of Concept

Prerequisites: Two registered users (attacker and victim). In the IDs below: attacker's project is 2, kanban view 8; victim's project is 1, kanban view 4.

Step 1: Attacker creates a fresh bucket in their own project.

Step 2: Attacker updates bucket 7, supplying project_view_id = victim's view ID. The URL chain is the attacker's, so CanUpdate passes; the body field is written through without further checks.

Step 3: Victim lists buckets in their own view; the attacker's bucket is now there, owned by the attacker.

After relocation the attacker can no longer reach the row (it lives in the victim's view), so only the victim can delete the graffiti. project_view_id is a sequential integer, so any tenant's view can be targeted by enumeration.

Impact

Any signed-in user can inject arbitrary-titled buckets into any other tenant's kanban view. Most likely exploitation here would be graffiti/defacement.

Fix

In (b *Bucket) Update, drop project_view_id from the Cols(...) allowlist (mass-assignment fix) and reject body payloads where project_view_id != bucket.ProjectViewID. If legitimate "move bucket between views" is a needed feature, expose it as a dedicated endpoint that calls CanUpdate against both the source and destination view.