Vulnerability-Lookup

GHSA-5PG6-M483-7VRG

Vulnerability from github – Published: 2026-08-28 16:52 – Updated: 2026-08-28 16:52

Summary

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

Details

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.

Severity

7.1 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.3.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "code.vikunja.io/api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55066"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-28T16:52:16Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nThe kanban endpoint `POST /api/v1/projects/{project}/views/{view}/buckets/{bucket}/tasks`\nmoves a task into a bucket. The task is identified by `task_id` in the **request\nbody**. The endpoint\u0027s authorization check (`TaskBucket.CanUpdate`) only verifies\nthat the caller may update the *project/view/bucket named in the URL* \u2014 it never\nchecks any permission on `task_id`.\n\nAny authenticated user can therefore supply another user\u0027s task ID (task IDs are\na global, sequential integer space) against a kanban bucket in their **own**\nproject. The server loads that victim task with no authorization check, returns\nits full contents in the response, and \u2014 when the target bucket is a \"done\"\nbucket \u2014 writes to the victim task\u0027s row.\n\nThis is the same vulnerability class Vikunja has already remediated for task\nrelations (CVE-2026-33676), task attachments (CVE-2026-33678), task comments\n(CVE-2026-33313) and CalDAV task read (CVE-2026-35598). `TaskBucket` is the\ntask-child operation that was missed.\n\n---\n\n## Root cause\n\n### 1. `task_id` is body-controlled and never permission-checked\n\n`pkg/models/kanban_task_bucket.go:32`:\n\n    type TaskBucket struct {\n        BucketID      int64 `... json:\"bucket_id\" param:\"bucket\"`\n        TaskID        int64 `... json:\"task_id\"`              // body-bound only \u2014 no param tag\n        ProjectViewID int64 `... json:\"project_view_id\" param:\"view\"`\n        ProjectID     int64 `xorm:\"-\" json:\"-\" param:\"project\"`\n        ...\n    }\n\nThe web handler `UpdateWeb` (`pkg/web/handler/update.go`) populates the struct via\n`ctx.Bind`, which binds both URL path params (`param:` tags) **and** the JSON body.\n`BucketID`, `ProjectViewID`, `ProjectID` come from the trusted URL; `TaskID` comes\nentirely from the attacker-controlled body.\n\n### 2. `CanUpdate` authorizes the URL, not the task\n\n`pkg/models/kanban_task_bucket.go:52`:\n\n    func (b *TaskBucket) CanUpdate(s *xorm.Session, a web.Auth) (bool, error) {\n        bucket := Bucket{ID: b.BucketID, ProjectID: b.ProjectID, ProjectViewID: b.ProjectViewID}\n        return bucket.canDoBucket(s, a)\n    }\n\n`canDoBucket` (`pkg/models/kanban_permissions.go:46`) resolves the bucket/view and\nends in `Project{ID: pv.ProjectID}.CanUpdate(s, a)` \u2014 a permission check on the\n**project from the URL**. `b.TaskID` is never referenced. The attacker owns that\nproject, so the check passes.\n\n### 3. The task is loaded and mutated with no authorization\n\n`updateTaskBucket` (`pkg/models/kanban_task_bucket.go:119`):\n\n    task := \u0026Task{ID: b.TaskID}\n    err = task.ReadOne(s, a)            // loads ANY task by ID \u2014 no permission check\n\n`Task.ReadOne` (`pkg/models/tasks.go:1967`) calls `GetTaskByIDSimple` +\n`addMoreInfoToTasks`; it performs no authorization (authorization normally lives\nin the separate `Task.CanRead`, which this internal call path bypasses).\n\n- **Read:** the fully populated victim task is assigned to `b.Task` (line 227) and\n  returned by the `Update` handler in the response `\"task\"` field.\n- **Write:** if the target bucket is the view\u0027s done bucket\n  (`view.DoneBucketID == b.BucketID \u0026\u0026 !task.Done`, line 141), the handler sets\n  `task.Done = true` and persists it to the victim\u0027s task row:\n\n      _, err = s.Where(\"id = ?\", task.ID).\n          Cols(\"done\", \"due_date\", \"start_date\", \"end_date\", \"done_at\").\n          Update(task)\n\n---\n\n## Proof of Concept\n\nThe attacker is any normal authenticated user. They first create their own kanban\nproject/view/bucket (free for every user), then:\n\n    POST /api/v1/projects/{ATTACKER_PROJECT}/views/{ATTACKER_VIEW}/buckets/{ATTACKER_BUCKET}/tasks HTTP/1.1\n    Host: TARGET\n    Authorization: Bearer {ATTACKER_JWT}\n    Content-Type: application/json\n\n    {\"task_id\": {VICTIM_TASK_ID}}\n\nThe `200` response body contains the victim task in full under `\"task\"` \u2014 title,\ndescription, dates, assignees, labels, attachment list, reactions. Task IDs are a\nglobal sequential counter, so iterating `task_id` enumerates every task on the\ninstance.\n\nIf `ATTACKER_BUCKET` is the done bucket of `ATTACKER_VIEW`, the same request also\nflips the victim task to done (`done = true`, `done_at` set).\n\n---\n\n## Impact\n\nAny authenticated low-privilege user can:\n\n- **Read any task on the instance** by sequential ID, across every other user,\n  project and organization \u2014 a full cross-tenant information disclosure of task\n  titles, descriptions, assignees, labels and attachment metadata.\n- **Modify any task\u0027s done state**, marking arbitrary victims\u0027 tasks done (or\n  clearing it) and altering `done_at`.\n\nVikunja\u0027s permission model is built specifically to isolate projects between\nusers; this endpoint defeats that isolation. It is the same impact and class that\nwarranted CVEs for task relations, attachments and comments.\n\n---\n\n## Suggested fix\n\nIn `TaskBucket.CanUpdate`, after the bucket/project check, also verify the caller\u0027s\npermission on the body-supplied task \u2014 mirroring the remediation already applied\nto task relations and attachments:\n\n    task := \u0026Task{ID: b.TaskID}\n    canUpdateTask, err := task.CanUpdate(s, a)\n    if err != nil || !canUpdateTask {\n        return false, err\n    }\n\n(Use `CanRead` if moving a readable-but-not-writable task into a bucket is intended;\n`CanUpdate` is the safer default since the operation can change the task\u0027s done\nstate.)\n\n---\n\n## References\n\n- CWE-639 Authorization Bypass Through User-Controlled Key\n- CWE-284 Improper Access Control\n- OWASP A01:2021 Broken Access Control\n- CVE-2026-33676, CVE-2026-33678, CVE-2026-33313, CVE-2026-35598 \u2014 the same\n  missing-authorization-on-task-child class, already remediated; this report is\n  the un-remediated `TaskBucket` sibling.\n\n## Additional notes\n\n- **The v2 API is affected too.** The same endpoint is exposed under `/api/v2/...`,\n  and both versions route through the shared model `TaskBucket.CanUpdate` /\n  `updateTaskBucket` in `pkg/models/kanban_task_bucket.go`. A model-level fix\n  closes v1 and v2 simultaneously; the regression test should assert both.\n\n- **Two fix altitudes.** The minimal fix checks the body-supplied `task_id` in\n  `TaskBucket.CanUpdate` (`task.CanUpdate`/`CanRead`). A broader fix makes\n  `Task.ReadOne` itself permission-aware, which also hardens other internal call\n  paths that rely on it \u2014 higher blast radius, weigh accordingly.\n\n- Side effects of the cross-tenant write confirmed across reports: flipping `done`\n  rewrites `done_at`/`due_date`/`start_date`/`end_date`, inserts a `task_buckets`\n  row, propagates done-state to other kanban views with a done bucket in the\n  victim\u0027s project, and triggers `updateDone` rescheduling for repeating tasks.",
  "id": "GHSA-5pg6-m483-7vrg",
  "modified": "2026-08-28T16:52:16Z",
  "published": "2026-08-28T16:52:16Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-5pg6-m483-7vrg"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/pull/3239"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/commit/36cdc2ce2be0b8ccc74227d178b92047d59cd65f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-vikunja/vikunja"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/releases/tag/v2.4.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Vikunja has cross-tenant IDOR in kanban move-task endpoint via unauthorized body task_id"
}

CVE-2026-55066 (GCVE-0-2026-55066)

Vulnerability from cvelistv5 – Published: 2026-08-28 16:51 – Updated: 2026-08-28 16:51

Title

Vikunja: Cross-tenant IDOR in kanban move-task endpoint via unauthorized body task_id

Summary

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.

Severity

7.1 (High)


                        
                          CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N

CWE

CWE-639 - Authorization Bypass Through User-Controlled Key

Assigner

GitHub_M mitre root

References

4 references

URL	Tags
https://github.com/go-vikunja/vikunja/security/ad…	x_refsource_CONFIRM
https://github.com/go-vikunja/vikunja/pull/3239	x_refsource_MISC
https://github.com/go-vikunja/vikunja/commit/36cd…	x_refsource_MISC
https://github.com/go-vikunja/vikunja/releases/ta…	x_refsource_MISC

Impacted products

1 product

Vendor	Product	Version
go-vikunja	vikunja	Affected: < 2.4.0

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "vikunja",
          "vendor": "go-vikunja",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 2.4.0"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "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."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 7.1,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "LOW",
            "privilegesRequired": "LOW",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-639",
              "description": "CWE-639: Authorization Bypass Through User-Controlled Key",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-28T16:51:48.114Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-5pg6-m483-7vrg",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-5pg6-m483-7vrg"
        },
        {
          "name": "https://github.com/go-vikunja/vikunja/pull/3239",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/go-vikunja/vikunja/pull/3239"
        },
        {
          "name": "https://github.com/go-vikunja/vikunja/commit/36cdc2ce2be0b8ccc74227d178b92047d59cd65f",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/go-vikunja/vikunja/commit/36cdc2ce2be0b8ccc74227d178b92047d59cd65f"
        },
        {
          "name": "https://github.com/go-vikunja/vikunja/releases/tag/v2.4.0",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/go-vikunja/vikunja/releases/tag/v2.4.0"
        }
      ],
      "source": {
        "advisory": "GHSA-5pg6-m483-7vrg",
        "discovery": "UNKNOWN"
      },
      "title": "Vikunja: Cross-tenant IDOR in kanban move-task endpoint via unauthorized body task_id"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-55066",
    "datePublished": "2026-08-28T16:51:48.114Z",
    "dateReserved": "2026-06-16T14:33:35.710Z",
    "dateUpdated": "2026-08-28T16:51:48.114Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.

Action not permitted

GHSA-5PG6-M483-7VRG

Summary

Root cause

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

2. CanUpdate authorizes the URL, not the task

3. The task is loaded and mutated with no authorization

Proof of Concept

Impact

Suggested fix

References

Additional notes

CVE-2026-55066 (GCVE-0-2026-55066)

Tags

Sightings

Nomenclature

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

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