Open-Source Security Intelligence

Know every vulnerability
before it knows you.

DevGuard continuously monitors your dependencies and alerts you when CVEs like this one affect your stack — with real-time threat intelligence built for developers.

Check if your repositories are affected!View on GitHub

GHSA-w2ch-4xgr-22ww

LowCVSS 2.3 / 10

Published Oct 9, 2026·Last modified Oct 9, 2026

Affected Components(1)

code.vikunja.io/api

0.9.0 – 2.6.0

Description

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

As owner, create project P_near with task near and project P_far with task far.
Share P_near with attacker at write permission (permission: 1). Do not share P_far.
As owner: PUT /api/v1/tasks/{near}/relations with {"other_task_id": far, "relation_kind": "related"} -> 200.
As attacker: GET /api/v1/tasks/{far} -> 403 (confirms no access).
As attacker: PUT /api/v1/tasks/{near}/relations with the same body -> 403 (create path is enforced).
As attacker: DELETE /api/v1/tasks/{near}/relations/related/{far} -> 200 "Successfully deleted."
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.

Upload your SBOM

Upload your own SBOM in CycloneDX 1.6 or higher (JSON) directly here to check your vulnerabilities.

Drag and drop some file here, or click to select

Risk Scores

Base Score

2.3

The vulnerability can be exploited over the network without needing physical access. It is easy for an attacker to exploit this vulnerability. An attacker needs basic access or low-level privileges. No user interaction is needed for the attacker to exploit this vulnerability.

Threat Intelligence

0.6

Limited exploitation activity has been observed. Close monitoring and planned remediation are recommended.

EPSS

N/A

Probability that this vulnerability will be exploited in the wild within the next 30 days.

Exploit

Not available

We did not find any exploit available. Neither in GitHub repositories nor in the Exploit-Database.

Browse More

Low severity

Scan your project

Continuously monitor your dependencies and get alerted when vulnerabilities like this one affect your stack.

Checkout DevGuard