KEVWire

Security intelligence, with context.

Response snapshot Oct 27, 2026, 16:31 UTC

Back to the wire
Permalink
VulnerabilityGHSA-fprf-r6rv-xg99

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

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.

Published Updated

At a glance

Exploited
Not known
Severity
Not scored yet
Chance of exploitation
Not estimated
Sources
1 source

What to do

GitHub lists first patched versions: code.vikunja.io/api: 2.7.0. Confirm the affected range and upgrade guidance in the exact advisory.

Read GitHub-reviewed advisory GHSA-fprf-r6rv-xg99 (opens a new tab)

What happened

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

Continue reading

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

Affected package ranges reported by GitHub: code.vikunja.io/api: >= 1.0.0-rc0, <= 2.6.0

Related technology

Sources

  1. Primary source

    GitHub-reviewed advisory GHSA-fprf-r6rv-xg99 (opens a new tab)

    The public advisory supplies the description, affected package/version ranges, and any listed CVSS metric. GitHub review is not local review.

    Published Checked

  2. Primary source

    GitHub public advisory API page (opens a new tab)

    The API page supplied GHSA-fprf-r6rv-xg99, its actual identifiers, source dates, and structured metrics.

    Published Date not suppliedChecked

Cite this record

For factual claims, cite the primary sources above; cite KEVWire for its compilation, dates, and classifications.

APA

KEVWire. (2026, October 27). Vikunja: Saved filter creation with an empty filter string recalculates task positions across all tenants. https://kevwire.com/record/GHSA-fprf-r6rv-xg99

MLA

"Vikunja: Saved filter creation with an empty filter string recalculates task positions across all tenants." KEVWire, 27 Oct. 2026, kevwire.com/record/GHSA-fprf-r6rv-xg99.

Chicago

KEVWire. "Vikunja: Saved filter creation with an empty filter string recalculates task positions across all tenants." Last modified October 27, 2026. https://kevwire.com/record/GHSA-fprf-r6rv-xg99.

Evidence summary (plain text)

Vikunja: Saved filter creation with an empty filter string recalculates task positions across all tenants (Oct 9, 2026).
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.

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`).
Sources:
GitHub-reviewed advisory GHSA-fprf-r6rv-xg99: https://github.com/advisories/GHSA-fprf-r6rv-xg99
GitHub public advisory API page: https://api.github.com/advisories?type=reviewed&per_page=100&sort=updated&direction=desc
Record ID: GHSA-fprf-r6rv-xg99.
Record origin: Ingested record.
AI evidence: Not assessed.
Known exploitation: Not assessed.
Zero-day status: Not assessed. KEV membership alone does not establish zero-day status.
About this data

This record was ingested from a data source. Retrieved: Oct 27, 2026, 16:25 UTC. Ingestion is not an independent editorial investigation.

A CISA KEV listing documents known exploitation, not necessarily a zero-day; absence from the catalog does not prove a vulnerability has never been exploited.

Technology tags indicate possible relevance, not verified exposure. Confirm the affected product, version, and configuration against your own inventory; KEVWire does not scan your systems.

A personal reading checklist on this device, not verified remediation.

Record JSON

Your account

Email alerts

Email alerts are not available yet. To follow your stack today, use its RSS feed, which honors your filters, or connect an AI agent through the API.

Suggest an improvement

Ideas, missing sources, corrections, and bugs are all welcome. No account needed. Suggestions are reviewed by a person before anything changes.

Record details

Record detail