Vikunja 1.0.0-rc0 before 2.7.0 Cross-Tenant Task Position Writes via Saved Filter Creation

CISA KEV is observed exploitation evidence. FIRST EPSS is a dated prediction of exploitation in the next 30 days. Missing scores are unknown. This collector requests predictions only for explicit CVE aliases in the public NuGet archive; Microsoft release views retain their existing prediction scope.

No collected risk observation for these identifiers. This does not establish absence of exploitation or a zero probability.

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.

Source published

17 Oct 2026 18:46:33 UTC

Source modified

19 Oct 2026 16:39:37 UTC

Observed here

23 Oct 2026 15:48:27 UTC

Source terms

CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: cve-program · CVE Program Terms of Use. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 4.0 · 5.3 CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N

CVSS 3.1 · 5.4 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L

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.

Source published

Oct 17, 2026, 6:46:33 PM (timezone not stated)

Source modified

Oct 19, 2026, 4:39:37 PM (timezone not stated)

Observed here

30 Oct 2026 01:56:39 UTC

Source terms

ENISA EUVD · source terms and attribution apply

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: euvd · ENISA EUVD · source terms and attribution apply. Source text is retained; field grouping and change labels are provided by ChangeIntel.

EUVD CVSS 4.0 · 5.3 CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N

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.

Source published

17 Oct 2026 19:16:34 UTC

Source modified

19 Oct 2026 21:14:14 UTC

Observed here

25 Oct 2026 05:17:13 UTC

Source terms

NIST NVD usage terms; underlying source attribution retained

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: nvd · NIST NVD usage terms; underlying source attribution retained. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 4.0 · [email protected] · Secondary · 5.3 CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

CVSS 3.1 · [email protected] · Secondary · 5.4 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L

### 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: ```go 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-filter-empty-scope-cross-tenant-positions-PoC.zip](https://github.com/user-attachments/files/32740623/vikunja-filter-empty-scope-cross-tenant-positions-PoC.zip) The attached archive contains `deployment/deploy.sh` (local Vikunja v2.6.0 on loopback with SQLite) and `poc/poc.sh`, which performs the full sequence: 1. Victim registers, creates a private project and a task. 2. Attacker registers, sets `default_project_id` to the victim's project via `PUT /api/v2/user/settings/general`, deletes their own Inbox, and now has zero accessible projects. 3. Control: `GET /api/v2/projects/{victim}` returns 403. 4. Attacker creates a saved filter with `{"filter":"","filter_include_nulls":true}`. 5. Verification: direct SQLite inspection shows `task_positions` rows referencing the victim's task in all four of the attacker's filter views. 6. Control: `GET /api/v2/projects/{filter_pseudo_project}/tasks` returns 0 items, so the written rows are not readable back through collection endpoints. Result: 10 checks passed on two consecutive runs, each from a wiped database. ### Impact An authenticated user, even one with no project access at all, causes the server to persist cross-tenant references: rows pointing at arbitrary other users' tasks are written into views the attacker controls. Task content is not exposed through the documented read paths (verified), so this is an integrity and availability issue rather than a direct disclosure: - Cross-tenant integrity violation. The `task_positions` state of the attacker's views now encodes other tenants' objects, against the access model the rest of the code enforces. - Write amplification and denial of service. One cheap request performs a full-table scan plus `4 x N` inserts, where N is the number of tasks in the instance. On an instance with 100,000 tasks that is 400,000 rows per request, and the request can be repeated without bound. CPU, IO and storage costs scale with instance size while attacker cost stays constant.

Source published

9 Oct 2026 20:57:38 UTC

Source modified

27 Oct 2026 15:30:03 UTC

Observed here

27 Oct 2026 15:46:08 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS_V3 · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L

Publisher rating · MODERATE

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: .

Source published

19 Oct 2026 21:08:26 UTC

Source modified

19 Oct 2026 21:40:46 UTC

Observed here

24 Oct 2026 13:19:41 UTC

Source terms

OSV · upstream source license applies

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · OSV · upstream source license applies. Source text is retained; field grouping and change labels are provided by ChangeIntel.