---
id: GHSA-w2ch-4xgr-22ww
title: >-
  Vikunja: Task relation deletion does not check read access to the other task,
  allowing cross-project relation removal
summary: >-
  Vikunja: Task relation deletion does not check read access to the other task,
  allowing cross-project relation removal
severity: low
cwe:
  - CWE-285
  - CWE-862
vendor: api
product: code.vikunja.io/api
ecosystem: go
affected:
  - 'code.vikunja.io/api >= 0.9, <= 2.5.0'
patched:
  - code.vikunja.io/api 2.6.0
published: '2026-10-09'
updated: '2026-10-09'
sourceUpdated: '2026-10-09T20:54:52Z'
source: GHSA
sourceUrl: 'https://github.com/advisories/GHSA-w2ch-4xgr-22ww'
references:
  - url: >-
      https://github.com/go-vikunja/vikunja/security/advisories/GHSA-w2ch-4xgr-22ww
  - url: 'https://github.com/go-vikunja/vikunja/pull/3688'
  - url: >-
      https://github.com/go-vikunja/vikunja/commit/077dc4de79ce6f1ab59215a2c7bf9b30423685f2
  - url: 'https://github.com/go-vikunja/vikunja/releases/tag/v2.6.0'
  - url: 'https://github.com/advisories/GHSA-w2ch-4xgr-22ww'
tags:
  - ghsa
  - go
ingestedAt: '2026-10-09T21:12:42.323Z'
---

## Overview

## Summary

Deleting a task relation only requires write access on the base task. Unlike relation creation, it does not verify that the caller can read the other task. A user with write access to one project can therefore delete relations whose other end lives in a project they have no access to. Since the delete removes both the forward and inverse rows, the relation also disappears for the other project's members.

## Details

`TaskRelation.CanCreate` (`pkg/models/task_relation_permissions.go:32-52`) requires write access on `TaskID` **and** read access on `OtherTaskID`.

`TaskRelation.CanDelete` (`pkg/models/task_relation_permissions.go:25-29`) only checks `Task{ID: rel.TaskID}.CanUpdate(s, a)`; `OtherTaskID` is never authorized.

`TaskRelation.Delete` (`pkg/models/task_relation.go:314-354`) then deletes both the `(task_id, other_task_id, kind)` row and its inverse, so the relation is removed from the far task as well.

Affects `DELETE /api/v1/tasks/{id}/relations/{kind}/{otherTaskId}` and the equivalent v2 endpoint.

## Impact

Low, integrity only. An authenticated user holding write permission on a shared project can remove task relations that link into projects they cannot read. No data is disclosed and no privilege is gained; the attacker cannot recreate the relation. The far project's owner sees the relation vanish without indication of who removed it.

Preconditions: the attacker has write access to a project containing a task that is already related to a task in a project they cannot access.

## Proof of Concept

1. As `owner`, create project `P_near` with task `near` and project `P_far` with task `far`.
2. Share `P_near` with `attacker` at write permission (`permission: 1`). Do not share `P_far`.
3. As `owner`: `PUT /api/v1/tasks/{near}/relations` with `{"other_task_id": far, "relation_kind": "related"}` -> 200.
4. As `attacker`: `GET /api/v1/tasks/{far}` -> 403 (confirms no access).
5. As `attacker`: `PUT /api/v1/tasks/{near}/relations` with the same body -> 403 (create path is enforced).
6. As `attacker`: `DELETE /api/v1/tasks/{near}/relations/related/{far}` -> 200 `"Successfully deleted."`
7. As `owner`: `GET /api/v1/tasks/{far}` -> `related_tasks` is now empty.

Reproduced against `vikunja/vikunja:2.5.0`.

## Recommended Fix

Make `CanDelete` mirror `CanCreate`: after checking `CanUpdate` on the base task, also require `CanRead` on `OtherTaskID`.

## Affected packages

- `code.vikunja.io/api >= 0.9, <= 2.5.0`

## Remediation

Upgrade to a patched release:

- `code.vikunja.io/api 2.6.0`