Vulnerabilities

Vulnerability · CVE-2026-111918

Vikunja: Saved filter creation with an empty filter string recalculates task positions across all tenants

Published Oct 9, 2026 · catalog updated Oct 18, 2026 · Vikunja: Saved filter creation

Open the advisory

Exploitation likelihood is not on this record for CVE-2026-111918. A missing EPSS score is not a low risk. Compare Vikunja: Saved filter creation with the linked advisory before you change production.

Severity

Medium5.4

Known exploitation

Not in CISA/VulnCheck KEV

EPSS

Not in the current FIRST EPSS dataset

Remediation

Advisory link

Affected products

Go code.vikunja.io/api

### 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 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 table keyed by . When a saved filter is created, ( ) calls ( ) which, for every default view it creates, calls with ( ). ( ) builds a and, for filter views ( ), resets the project scope to zero and injects the saved filter's filter string. The scope of the subsequent search is derived from ( ), which for returns exactly the projects the requesting user can access. Inside ( ), the WHERE clause is assembled at line 632: is only set when and only when the caller opted into the favorites arm, which never does. With zero accessible projects, an empty filter string (which produces no filter condition in ) and no search string, all four children of the are invalid. go-xorm's condition builders silently drop invalid children, so the query becomes 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 rows, every one of them referencing tasks the requesting user has no relationship with, including tasks in other users' private p