Vikunja CVE-2026-91984

Exploitation requires a valid authenticated Vikunja session (CVSS PR:L) against a version below 2.6.0, plus knowledge or successful guessing of a project_view_id that belongs to a project view the attacker is not a member of - the vulnerability is that this identifier is never validated against the task's own project, not that it is secret. The attack is only useful in instances that host multiple projects or tenants with access separation; single-user or single-project instances have nothing to cross over into. What limits impact: the CVSS vector shows no confidentiality and no availability effect (VC:N/VA:N) and only a low integrity impact, so an attacker cannot read the victim's data or take the service down through this path. The flaw is reachable on default installations of the affected versions (no special feature flag or non-default configuration is documented as required), and it does not depend on user interaction.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N, VC:N/VI:L/VA:N) describes a low-complexity, network-reachable, authenticated integrity-only flaw, and the score of 5.3 is consistent with that: no confidentiality or availability loss, so this is not a data-exfiltration or denial-of-service issue. The PR:L metric is the decisive constraint - an attacker must already hold a valid account on the instance - so on a single-tenant or invite-only deployment the blast radius is largely internal, while multi-tenant or open-registration instances face genuine cross-tenant integrity risk, and even a mid-sized municipal IT team in bytom should treat this as urgent only if its Vikunja instance serves multiple mutually distrusting tenants. No EPSS score, KEV status, or public proof-of-concept was supplied, so there is no evidence of active exploitation and the real-world likelihood should be treated as opportunistic rather than confirmed; note the CVSS data is 4.0 while the header score is 5.3, and the tag 'Authentication Bypass' overstates the issue (this is authorization, not authentication), so downstream severity inheritance should be verified against the vendor advisory.

An attacker with an ordinary Vikunja account authenticates normally, then sends POST or PUT requests to the task-position endpoints while substituting a project_view_id belonging to a different tenant's project view. The server accepts the key without ownership validation and writes the position row into the foreign view, corrupting that team's task ordering and letting the attacker inject arbitrary task references into views they should never touch. The technique is simple to automate once the attacker knows or guesses a valid view identifier, and no public proof-of-concept was identified at the time of analysis.