CVE-2026-111918

Vikunja from 1.0.0-rc0 before 2.7.0 contains an improper authorization vulnerability in RecalculateTaskPositions that allows authenticated users with zero accessible projects to write task_positions rows for all tasks instance-wide. Attackers can delete their Inbox after repointing default_project_id, then create empty-filter saved filters to persist cross-tenant references and amplify writes for denial of service.

Vikunja from 1.0.0-rc0 before 2.7.0 contains an improper authorization vulnerability in RecalculateTaskPositions that allows authenticated users with zero accessible projects to write task_positions rows for all tasks instance-wide. Attackers can delete their Inbox after repointing default_project_id, then create empty-filter saved filters to persist cross-tenant references and amplify writes for denial of service.

Summary

In Vikunja v2.6.0 the task position recalculation that runs when a saved filter view is created fails open when the requesting user has no accessible projects. Instead of aborting, the search that feeds the recalculation loses its project scope entirely and returns every task in the instance. The server then writes one task_positions row per task per view (four views per filter) into views owned by the requesting user, including rows that reference tasks of other tenants the user can never see. Any authenticated user can trigger this. The impact is a cross-tenant integrity violation, a single-request write amplification primitive that scales with instance size, and a violation of the invariant stated in the fix for GHSA-w39f-h553-h2mx that position writes are scoped by project read access.

Details

Vikunja computes kanban and list ordering in a shared task_positions table keyed by (task_id, project_view_id). When a saved filter is created, SavedFilter.Create (pkg/models/saved_filters.go:130) calls CreateDefaultViewsForProject (pkg/models/project_view.go:816) which, for every default view it creates, calls RecalculateTaskPositions with addExistingTasksToView = true (pkg/models/project_view.go:447).

RecalculateTaskPositions (pkg/models/task_position.go:312) builds a TaskCollection and, for filter views (view.ProjectID < -1), resets the project scope to zero and injects the saved filter's filter string. The scope of the subsequent search is derived from getRelevantProjectsFromCollection (pkg/models/task_collection.go:188), which for ProjectID == 0 returns exactly the projects the requesting user can access.

Inside dbTaskSearcher.Search (pkg/models/task_search.go), the WHERE clause is assembled at line 632:

cond := builder.And(builder.Or(projectIDCond, favoritesCond), where, filterCond)

projectIDCond is only set when len(opts.projectIDs) > 0 and favoritesCond only when the caller opted into the favorites arm, which RecalculateTaskPositions never does. With zero accessible projects, an empty filter string (which produces no filter condition in getTaskFiltersFromFilterString) and no search string, all four children of the builder.And are invalid. go-xorm's condition builders silently drop invalid children, so the query becomes SELECT ... FROM tasks with no WHERE clause at all.

The result is written back unconditionally: the function deletes the view's position rows and bulk-inserts one row per returned task per view. Because the filter creation path runs this for four default views, one request writes 4 x total_task_count rows, every one of them referencing tasks the requesting user has no relationship with, including tasks in other users' private projects.

Reaching the zero-project precondition does not require any bug beyond this one. UpdateUserGeneralSettings (pkg/models/user_settings.go:105) assigns default_project_id from the request body without validating that the referenced project exists or belongs to the caller. A user can therefore point their default project at any project id, which unblocks deleting their own Inbox (deletion is refused only while the Inbox is the default project, error 3012 in pkg/models/error.go:482). After the Inbox is gone, getRawProjectsForUser returns an empty list.

Two neighboring controls confirm the intended invariant exists elsewhere and is enforced in sibling paths. The event-driven filter update path gates candidate filters on the filter owner's access to each task's project (matchTasksToViewsOfFilter, introduced by commit b1ad4063e7), and the fix for GHSA-w39f-h553-h2mx validates position target views. The recalculation path on filter creation has no equivalent gate and contradicts the advisory statement that recalculation "aborts on its own project read-access check".

PoC

…

Vikunja from 1.0.0-rc0 before 2.7.0 contains an improper authorization vulnerability in RecalculateTaskPositions that allows authenticated users with zero accessible projects to write task_positions rows for all tasks instance-wide. Attackers can delete their Inbox after repointing default_project_id, then create empty-filter saved filters to persist cross-tenant references and amplify writes for denial of service.

Vikunja from 1.0.0-rc0 before 2.7.0 contains an improper authorization vulnerability in RecalculateTaskPositions that allows authenticated users with zero accessible projects to write task_positions rows for all tasks instance-wide. Attackers can delete their Inbox after repointing default_project_id, then create empty-filter saved filters to persist cross-tenant references and amplify writes for denial of service.

Vikunja from 1.0.0-rc0 before 2.7.0 contains an improper authorization vulnerability in RecalculateTaskPositions that allows authenticated users with zero accessible projects to write task_positions rows for all tasks instance-wide. Attackers can delete their Inbox after repointing default_project_id, then create empty-filter saved filters to persist cross-tenant references and amplify writes for denial of service.

Summary

In Vikunja v2.6.0 the task position recalculation that runs when a saved filter view is created fails open when the requesting user has no accessible projects. Instead of aborting, the search that feeds the recalculation loses its project scope entirely and returns every task in the instance. The server then writes one task_positions row per task per view (four views per filter) into views owned by the requesting user, including rows that reference tasks of other tenants the user can never see. Any authenticated user can trigger this. The impact is a cross-tenant integrity violation, a single-request write amplification primitive that scales with instance size, and a violation of the invariant stated in the fix for GHSA-w39f-h553-h2mx that position writes are scoped by project read access.

Details

Vikunja computes kanban and list ordering in a shared task_positions table keyed by (task_id, project_view_id). When a saved filter is created, SavedFilter.Create (pkg/models/saved_filters.go:130) calls CreateDefaultViewsForProject (pkg/models/project_view.go:816) which, for every default view it creates, calls RecalculateTaskPositions with addExistingTasksToView = true (pkg/models/project_view.go:447).

RecalculateTaskPositions (pkg/models/task_position.go:312) builds a TaskCollection and, for filter views (view.ProjectID < -1), resets the project scope to zero and injects the saved filter's filter string. The scope of the subsequent search is derived from getRelevantProjectsFromCollection (pkg/models/task_collection.go:188), which for ProjectID == 0 returns exactly the projects the requesting user can access.

Inside dbTaskSearcher.Search (pkg/models/task_search.go), the WHERE clause is assembled at line 632:

cond := builder.And(builder.Or(projectIDCond, favoritesCond), where, filterCond)

projectIDCond is only set when len(opts.projectIDs) > 0 and favoritesCond only when the caller opted into the favorites arm, which RecalculateTaskPositions never does. With zero accessible projects, an empty filter string (which produces no filter condition in getTaskFiltersFromFilterString) and no search string, all four children of the builder.And are invalid. go-xorm's condition builders silently drop invalid children, so the query becomes SELECT ... FROM tasks with no WHERE clause at all.

The result is written back unconditionally: the function deletes the view's position rows and bulk-inserts one row per returned task per view. Because the filter creation path runs this for four default views, one request writes 4 x total_task_count rows, every one of them referencing tasks the requesting user has no relationship with, including tasks in other users' private projects.

Reaching the zero-project precondition does not require any bug beyond this one. UpdateUserGeneralSettings (pkg/models/user_settings.go:105) assigns default_project_id from the request body without validating that the referenced project exists or belongs to the caller. A user can therefore point their default project at any project id, which unblocks deleting their own Inbox (deletion is refused only while the Inbox is the default project, error 3012 in pkg/models/error.go:482). After the Inbox is gone, getRawProjectsForUser returns an empty list.

Two neighboring controls confirm the intended invariant exists elsewhere and is enforced in sibling paths. The event-driven filter update path gates candidate filters on the filter owner's access to each task's project (matchTasksToViewsOfFilter, introduced by commit b1ad4063e7), and the fix for GHSA-w39f-h553-h2mx validates position target views. The recalculation path on filter creation has no equivalent gate and contradicts the advisory statement that recalculation "aborts on its own project read-access check".

PoC

…

Vikunja: Saved filter creation with an empty filter string recalculates task positions across all tenants in code.vikunja.io/api.

NOTE: The source advisory for this report contains additional versions that could not be automatically mapped to standard Go module versions.

(If this is causing false-positive reports from vulnerability scanners, please suggest an edit to the report.)

The additional affected modules and versions are: .