GHSA-FPRF-R6RV-XG99: Cross-Tenant Task Position Recalculation in Vikunja

Vikunja is an open-source task management application designed to support multi-tenant operational environments. Multi-tenancy relies on database boundary isolation to ensure that tasks, user filters, and project configurations created by one tenant remain strictly segregated from all other tenants sharing the application infrastructure.

The vulnerability designated as GHSA-FPRF-R6RV-XG99 is a cross-tenant state alteration bug within the saved filter management system. When an authenticated user creates a saved filter containing an empty filter parameter, the application logic fails to restrict the subsequent recalculation of task positions to the user's specific tenant context.

This improper scope restriction permits an unprivileged attacker in one tenant workspace to involuntarily reorder and update task positions across every tenant hosted on the target Vikunja instance, violating multi-tenant isolation guarantees.

The root cause of GHSA-FPRF-R6RV-XG99 originates from inadequate constraint enforcement during saved filter initialization and background task reordering routines. In Vikunja, saved filters allow users to store criteria queries that organize and display tasks dynamically.

When a filter string is populated with criteria (such as priority level or project tags), the backend constructs a tenant-scoped database query that applies strictly to the current user context. However, when an empty filter string ("") is processed, the criteria evaluation engine defaults to an unconstrained query pattern.

Because the background position recalculation task omits tenant predicate checks (tenant_id = ?) when handling empty filter conditions, the reordering script evaluates every task row present in the central database table. This causes universal task position recalculation across all tenant spaces.

The execution path transitions from an incoming user API request to an un-scoped database mutation across tenant boundaries.

When evaluating filter persistence, the application invokes a routine designed to recalculate positional indexes for tasks belonging to the filter. Because the empty string bypasses criteria parsing, the underlying query generator fails to attach tenant context identifiers, resulting in global UPDATE execution.

Exploitation requires basic authenticated access to any valid account within a multi-tenant Vikunja deployment. Elevated administrative privileges are not required to trigger the issue.

An attacker sends an HTTP POST request to the API endpoint responsible for saved filter creation, supplying an empty string inside the filter parameter payload:

{
  "title": "Malicious Filter",
  "filter": ""
}

Upon parsing this request, the backend immediately executes the global task index recalculation. Task ordering indexes belonging to external organizations and unrelated users are overwritten, disrupting sequence views and custom board arrangements across the entire system.

The impact of GHSA-FPRF-R6RV-XG99 affects both data integrity and service availability in multi-tenant deployment scenarios. While direct exfiltration or unauthorized read access to task content does not occur, multi-tenant security guarantees are breached.

Data integrity is compromised as task position values across all tenants are modified without authorization. This disrupts project management workflows, custom task reordering, and Kanban view arrangements for all active users on the server.

From an availability perspective, executing batch updates across all database records in large multi-tenant instances creates severe database CPU usage spikes and table lock contention, leading to response timeouts or denial of service.

Deployments running Vikunja should update to patched software versions that enforce strict tenant filtering on all filter creation and task position recalculation operations.

Application developers must ensure that all background database routines incorporate mandatory tenant ID scoping predicates, preventing queries from operating outside the requester's context even when parameter evaluation produces empty or default filter trees.

> [!NOTE] > If an immediate patch deployment is not feasible, web application firewalls (WAF) or API gateways can be configured to filter out requests targeting the saved filter creation route containing empty filter field values.