GHSA-w2ch-4xgr-22ww: Go/code.vikunja.io/api vulnerability

Q: Which environments are exposed to this authorization gap?

Deployments are exposed where a user has write permission on a task in one shared project and that task has a relation to a task in another project the user cannot read.

Q: What access does an attacker need?

The attacker must be authenticated and have write access to the base task's project. They do not need read access to the related task or its project.

Q: Which API operations should be reviewed for potentially affected activity?

Review relation deletions through DELETE /api/v1/tasks/{id}/relations/{kind}/{otherTaskId} and the equivalent v2 endpoint. A successful deletion removes both the forward relation and its inverse.

Published Oct 9, 2026

Updated

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/taskrelationpermissions.go:32-52) requires write access on TaskID and read access on OtherTaskID.

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

TaskRelation.Delete (pkg/models/taskrelation.go:314-354) then deletes both the (taskid, othertaskid, 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 Pnear with task near and project Pfar with task far. 2. Share Pnear with attacker at write permission (permission: 1). Do not share Pfar. 3. As owner: PUT /api/v1/tasks/{near}/relations with {"othertaskid": far, "relationkind": "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} -> relatedtasks 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 Software

1 affected componentFixes available

go/code.vikunja.io/api>=0.9<=2.5.0

2.6.0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

Upgrade
Upgrade go/code.vikunja.io/api to a version that resolves this vulnerability.
Fixed in 2.6.0
Compensating control
Update TaskRelation.CanDelete in pkg/models/task_relation_permissions.go to mirror CanCreate: after requiring CanUpdate on TaskID, also require CanRead on OtherTaskID.

Event History

Oct 9, 2026

Advisory Published

via GitHub·08:54 PM

Data Sourced

via GitHub·08:54 PM

DescriptionWeaknessAffected Software

Frequently Asked Questions

Which environments are exposed to this authorization gap?

Deployments are exposed where a user has write permission on a task in one shared project and that task has a relation to a task in another project the user cannot read.

What access does an attacker need?

The attacker must be authenticated and have write access to the base task's project. They do not need read access to the related task or its project.

Which API operations should be reviewed for potentially affected activity?

Review relation deletions through DELETE /api/v1/tasks/{id}/relations/{kind}/{otherTaskId} and the equivalent v2 endpoint. A successful deletion removes both the forward relation and its inverse.

GHSA-w2ch-4xgr-22ww: Go/code.vikunja.io/api vulnerability

Affected Software

Remediation

Event History

Frequently Asked Questions

Which environments are exposed to this authorization gap?

What access does an attacker need?

Which API operations should be reviewed for potentially affected activity?

Company

Resources

Contact

Frequently Asked Questions

Which environments are exposed to this authorization gap?

What access does an attacker need?

Which API operations should be reviewed for potentially affected activity?