Summary
Vikunja: Task relation deletion does not check read access to the other task, allowing cross-project relation removal
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.
Proof of Concept
- As
owner, create projectP_nearwith tasknearand projectP_farwith taskfar. - Share
P_nearwithattackerat write permission (permission: 1). Do not shareP_far. - As
owner:PUT /api/v1/tasks/{near}/relationswith{"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}/relationswith 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_tasksis now empty.
Reproduced against vikunja/vikunja:2.5.0.
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.
The application does not perform an authorization check before performing a sensitive operation. Typical impact: unauthorized access to restricted functionality or data.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Make CanDelete mirror CanCreate: after checking CanUpdate on the base task, also require CanRead on OtherTaskID.
Frequently Asked Questions
- What is GHSA-W2CH-4XGR-22WW? GHSA-W2CH-4XGR-22WW is a low-severity missing authorization vulnerability in code.vikunja.io/api (go), affecting versions >= 0.9, <= 2.5.0. It is fixed in 2.6.0. The application does not perform an authorization check before performing a sensitive operation.
- Which versions of code.vikunja.io/api are affected by GHSA-W2CH-4XGR-22WW? code.vikunja.io/api (go) versions >= 0.9, <= 2.5.0 is affected.
- Is there a fix for GHSA-W2CH-4XGR-22WW? Yes. GHSA-W2CH-4XGR-22WW is fixed in 2.6.0. Upgrade to this version or later.
- Is GHSA-W2CH-4XGR-22WW exploitable, and should I be worried? Whether GHSA-W2CH-4XGR-22WW is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-W2CH-4XGR-22WW is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-W2CH-4XGR-22WW? Upgrade
code.vikunja.io/apito 2.6.0 or later.