Vikunja EUVD-2026-103303

Requires a valid authenticated account on the Vikunja instance (PR:L) AND a specific account state - zero accessible projects - which the attacker can engineer by repointing default_project_id and deleting their Inbox. The trigger is the normal SavedFilter.Create flow using a saved filter with an EMPTY filter string and no search string, which causes RecalculateTaskPositions (with addExistingTasksToView=true) to run a search whose project scope collapses to nothing and whose WHERE clause is dropped by go-xorm, returning every task instance-wide. Limiting factors that reduce real-world risk: exploitation is impossible for anonymous/unauthenticated attackers, the impact is meaningful mainly in multi-tenant deployments (single-tenant instances see no cross-tenant exposure), the attacker gains no read access to other tenants' task contents, and the user must deliberately reach the unusual zero-accessible-projects state rather than it being a default configuration.

This is a moderate-severity, authenticated authorization flaw (CWE-863), not a critical issue despite the network attack vector. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:L) scoring 5.3 is internally consistent with the description: exploitation requires an authenticated low-privilege account (PR:L), is network-reachable and low-complexity, yields no confidentiality impact (the attacker still cannot read other tenants' task contents) but low integrity and low availability impact via cross-tenant writes and write amplification. No EPSS score, CISA KEV listing, SSVC decision, or public POC was supplied, so there is no signal of active or probable exploitation - exploitation status is therefore 'no public exploit identified at time of analysis.' The realistic risk is a logged-in, same-instance abuser degrading integrity/availability in multi-tenant deployments, rather than an externally weaponizable mass-exploitation threat; the low VC and the requirement for a non-default account state (zero accessible projects) further cap real-world urgency. Note a data conflict to verify with the vendor: the description states the fix is 2.7.0 and the flawed behavior is described as present 'in v2.6.0,' while the GitHub package metadata lists 'fixed in: None' for the range >= 1.0.0-rc0, <= 2.6.0 - treat 2.7.0 as the likely fixed version but confirm against the GHSA advisory.

An authenticated low-privilege user on a shared multi-tenant Vikunja instance manipulates their account into having zero accessible projects (deleting their Inbox after repointing default_project_id), then creates a saved filter with an empty filter string. Because the position-recalculation search fails open and loses its project scope, the server writes task_positions rows for every task in the entire instance - including other tenants' tasks - into views owned by the attacker, producing a single-request write-amplification primitive that scales with instance size for denial of service. No public exploit code is identified at time of analysis, and the attack is low-complexity but requires a valid account.