CVE-2026-55065

Vikunja is an open-source self-hosted task management platform. From 0.24.6 until 2.4.0, DELETE /api/v1/projects/:project/views/:view permits an authenticated user to supply a view identifier from another project while authorizing only against an attacker-controlled project identifier. ProjectView.CanDelete in pkg/models/project_view_permissions.go does not establish that the view belongs to the path project, and ProjectView.Delete in pkg/models/project_view.go continues after the scoped project_views delete affects no rows. Its subsequent deletes select task_buckets and task_positions only by project_view_id, allowing cross-tenant destruction of Kanban assignments and ordering while leaving the victim view and tasks intact. This issue is fixed in version 2.4.0.

Vikunja is an open-source self-hosted task management platform. From 0.24.6 until 2.4.0, DELETE /api/v1/projects/:project/views/:view permits an authenticated user to supply a view identifier from another project while authorizing only against an attacker-controlled project identifier. ProjectView.CanDelete in pkg/models/project_view_permissions.go does not establish that the view belongs to the path project, and ProjectView.Delete in pkg/models/project_view.go continues after the scoped project_views delete affects no rows. Its subsequent deletes select task_buckets and task_positions only by project_view_id, allowing cross-tenant destruction of Kanban assignments and ordering while leaving the victim view and tasks intact. This issue is fixed in version 2.4.0.

Summary

A user with only a single self-owned project can permanently destroy the Kanban bucket assignments (task_buckets) and task ordering (task_positions) of any other project view in the entire instance. The ProjectView.Delete model method runs three SQL statements: the first is properly scoped to (view_id, project_id), but the next two cascading deletes on task_buckets and task_positions filter only on the URL-supplied project_view_id. The permission check (CanDelete) gates on Admin of the URL :project but never confirms that the URL :view actually belongs to that project.

Details

ProjectView.Delete (file: pkg/models/project_view.go, line 250) cascades on the bare pv.ID for the second and third deletes, ignoring pv.ProjectID:

func (pv *ProjectView) Delete(s *xorm.Session, _ web.Auth) (err error) {
    _, err = s.
        Where("id = ? AND project_id = ?", pv.ID, pv.ProjectID).   // (a) scoped — OK
        Delete(&ProjectView{})
    if err != nil {
        return
    }

    _, err = s.Where("project_view_id = ?", pv.ID).Delete(&TaskBucket{})    // (b) UNSCOPED
    if err != nil {
        return
    }

    _, err = s.Where("project_view_id = ?", pv.ID).Delete(&TaskPosition{})  // (c) UNSCOPED
    return
}

pv.ID and pv.ProjectID come straight from the URL path via c.Bind — see the param tags on the struct (pkg/models/project_view.go, lines 133–137):

type ProjectView struct {
    ID        int64 `xorm:"autoincr not null unique pk" json:"id" param:"view"`
    ...
    ProjectID int64 `xorm:"not null index" json:"project_id" param:"project"`
    ...
}

The route is registered with both params in pkg/routes/routes.go, line 791:

a.DELETE("/projects/:project/views/:view", projectViewProvider.DeleteWeb)

CanDelete (file: pkg/models/project_view_permissions.go, line 38) gates only on Admin of the URL :project:

func (pv *ProjectView) CanDelete(s *xorm.Session, a web.Auth) (bool, error) {
    if isInstanceAdmin(s, a) {
        return true, nil
    }
    filterID := GetSavedFilterIDFromProjectID(pv.ProjectID)
    if filterID > 0 { ... }

    pp := pv.getProject()              // = &Project{ID: pv.ProjectID}  (URL path)
    return pp.IsAdmin(s, a)            // only checks admin on URL :project
}

There is no check that the view (pv.ID) actually belongs to that project. The first SQL inside Delete (the WHERE id = ? AND project_id = ? clause) compensates for the project_views table only. xorm silently returns 0 affected rows on a mismatch — no error — and the function continues. The next two statements then run unconditionally on pv.ID alone.

Why other neighbouring code paths are not vulnerable, for context:

• Bucket.canDoBucket (pkg/models/kanban_permissions.go, line 46) loads the bucket from the DB and re-couples the URL project via GetProjectViewByIDAndProject(viewID, projectID), which WHERE id = ? AND project_id = ? — mismatched URL :project returns an error. Safe.
• ProjectView.Update (pkg/models/project_view.go, line 412) calls the same GetProjectViewByIDAndProject before applying the update. Safe.
• Project.UpdateProject cascades use s.In("project_view_id", viewIDs).Delete(&Bucket{}) (pkg/models/project.go, line 1396) where viewIDs is loaded from the DB inside an authorised project-delete context. Safe.

The same shape (load-by-URL-id, then cascade-without-coupling) was the root cause of GHSA-jfmm-mjcp-8wq2 (attachment IDOR) and GHSA-2vq4-854f-5c72 (project reparenting). The view-delete cascade has not been audited the same way.

PoC

Prerequisites

• An authenticated account on the target Vikunja instance. No special role is required — local-auth registration is enough; the attacker becomes Admin of any project they create via the OwnerID field set in CreateProject (pkg/models/project.go, line 1021).
• Knowledge of any victim view ID. View IDs are…

Vikunja is an open-source self-hosted task management platform. From 0.24.6 until 2.4.0, DELETE /api/v1/projects/:project/views/:view permits an authenticated user to supply a view identifier from another project while authorizing only against an attacker-controlled project identifier. ProjectView.CanDelete in pkg/models/project_view_permissions.go does not establish that the view belongs to the path project, and ProjectView.Delete in pkg/models/project_view.go continues after the scoped project_views delete affects no rows. Its subsequent deletes select task_buckets and task_positions only by project_view_id, allowing cross-tenant destruction of Kanban assignments and ordering while leaving the victim view and tasks intact. This issue is fixed in version 2.4.0.

Vikunja is an open-source self-hosted task management platform. From 0.24.6 until 2.4.0, DELETE /api/v1/projects/:project/views/:view permits an authenticated user to supply a view identifier from another project while authorizing only against an attacker-controlled project identifier. ProjectView.CanDelete in pkg/models/project_view_permissions.go does not establish that the view belongs to the path project, and ProjectView.Delete in pkg/models/project_view.go continues after the scoped project_views delete affects no rows. Its subsequent deletes select task_buckets and task_positions only by project_view_id, allowing cross-tenant destruction of Kanban assignments and ordering while leaving the victim view and tasks intact. This issue is fixed in version 2.4.0.

Summary

A user with only a single self-owned project can permanently destroy the Kanban bucket assignments (task_buckets) and task ordering (task_positions) of any other project view in the entire instance. The ProjectView.Delete model method runs three SQL statements: the first is properly scoped to (view_id, project_id), but the next two cascading deletes on task_buckets and task_positions filter only on the URL-supplied project_view_id. The permission check (CanDelete) gates on Admin of the URL :project but never confirms that the URL :view actually belongs to that project.

Details

ProjectView.Delete (file: pkg/models/project_view.go, line 250) cascades on the bare pv.ID for the second and third deletes, ignoring pv.ProjectID:

func (pv *ProjectView) Delete(s *xorm.Session, _ web.Auth) (err error) {
    _, err = s.
        Where("id = ? AND project_id = ?", pv.ID, pv.ProjectID).   // (a) scoped — OK
        Delete(&ProjectView{})
    if err != nil {
        return
    }

    _, err = s.Where("project_view_id = ?", pv.ID).Delete(&TaskBucket{})    // (b) UNSCOPED
    if err != nil {
        return
    }

    _, err = s.Where("project_view_id = ?", pv.ID).Delete(&TaskPosition{})  // (c) UNSCOPED
    return
}

pv.ID and pv.ProjectID come straight from the URL path via c.Bind — see the param tags on the struct (pkg/models/project_view.go, lines 133–137):

type ProjectView struct {
    ID        int64 `xorm:"autoincr not null unique pk" json:"id" param:"view"`
    ...
    ProjectID int64 `xorm:"not null index" json:"project_id" param:"project"`
    ...
}

The route is registered with both params in pkg/routes/routes.go, line 791:

a.DELETE("/projects/:project/views/:view", projectViewProvider.DeleteWeb)

CanDelete (file: pkg/models/project_view_permissions.go, line 38) gates only on Admin of the URL :project:

func (pv *ProjectView) CanDelete(s *xorm.Session, a web.Auth) (bool, error) {
    if isInstanceAdmin(s, a) {
        return true, nil
    }
    filterID := GetSavedFilterIDFromProjectID(pv.ProjectID)
    if filterID > 0 { ... }

    pp := pv.getProject()              // = &Project{ID: pv.ProjectID}  (URL path)
    return pp.IsAdmin(s, a)            // only checks admin on URL :project
}

There is no check that the view (pv.ID) actually belongs to that project. The first SQL inside Delete (the WHERE id = ? AND project_id = ? clause) compensates for the project_views table only. xorm silently returns 0 affected rows on a mismatch — no error — and the function continues. The next two statements then run unconditionally on pv.ID alone.

Why other neighbouring code paths are not vulnerable, for context:

• Bucket.canDoBucket (pkg/models/kanban_permissions.go, line 46) loads the bucket from the DB and re-couples the URL project via GetProjectViewByIDAndProject(viewID, projectID), which WHERE id = ? AND project_id = ? — mismatched URL :project returns an error. Safe.
• ProjectView.Update (pkg/models/project_view.go, line 412) calls the same GetProjectViewByIDAndProject before applying the update. Safe.
• Project.UpdateProject cascades use s.In("project_view_id", viewIDs).Delete(&Bucket{}) (pkg/models/project.go, line 1396) where viewIDs is loaded from the DB inside an authorised project-delete context. Safe.

The same shape (load-by-URL-id, then cascade-without-coupling) was the root cause of GHSA-jfmm-mjcp-8wq2 (attachment IDOR) and GHSA-2vq4-854f-5c72 (project reparenting). The view-delete cascade has not been audited the same way.

PoC

Prerequisites

• An authenticated account on the target Vikunja instance. No special role is required — local-auth registration is enough; the attacker becomes Admin of any project they create via the OwnerID field set in CreateProject (pkg/models/project.go, line 1021).
• Knowledge of any victim view ID. View IDs are…