CVE-2026-91984

Vikunja: Cross-tenant task-position rows can be injected into arbitrary project views via the unvalidated projectviewid in the task position endpoint (v1 and v2)

Impact summary: a genuine broken-object-level-authorization defect (CWE-639) with no demonstrated confidentiality, integrity, or availability impact. The injected rows are invisible to the victim (view listings filter by project), order-preserving (any position collision is respaced between the same neighbours), and self-healing (any legitimate recalculation of the view deletes and rebuilds all its position rows). No read access, no privilege gain, no data destruction, and no usable DoS. Rated low, the fix is defense-in-depth, and its main value is preventing this wrong-object authorization from becoming a real cross-tenant leak should any future read path join task_positions without re-checking task-project access.

Broken object-level authorization on the write side (CWE-639, CWE-863: the authorization decision uses one resource dimension, the task, while the write targets another, the view). Any authenticated user holding a single writable task can persist rows into any other tenant's view state instance-wide (view IDs sequential and enumerable). The recalculation/lock path is not usable cross-tenant: a low position (< 0.01) enters the branch but RecalculateTaskPositions fails its own project read-access check and rolls back before recalculating (on MySQL/PostgreSQL a FOR UPDATE lock on the view row is taken one statement earlier in the same transaction, but released immediately on that rollback; SQLite takes no lock), so there is no meaningful availability angle. No confidentiality breach was demonstrated (victim listings filter by project), and the pollution is recoverable. Suggested fix: in CanUpdate or before the upsert, load the view by tp.ProjectViewID and require view.ProjectID == task.ProjectID (and/or caller access to the view's project), mirroring the bucket-side fix for GHSA-569v.

The application does not correctly enforce access controls, allowing a principal to access resources or operations beyond their granted permissions. Typical impact: unauthorized data access or execution of privileged operations.

Kodem intelligence

Already deployed Kodem?

1. What is CVE-2026-91984? CVE-2026-91984 is a medium-severity incorrect authorization vulnerability in code.vikunja.io/api (go), affecting versions <= 2.5.0. It is fixed in 2.6.0. The application does not correctly enforce access controls, allowing a principal to access resources or operations beyond their granted permissions.
2. Which versions of code.vikunja.io/api are affected by CVE-2026-91984? code.vikunja.io/api (go) versions <= 2.5.0 is affected.
3. Is there a fix for CVE-2026-91984? Yes. CVE-2026-91984 is fixed in 2.6.0. Upgrade to this version or later.
4. Is CVE-2026-91984 exploitable, and should I be worried? Whether CVE-2026-91984 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
5. What actually determines whether CVE-2026-91984 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
6. How do I fix CVE-2026-91984? Upgrade code.vikunja.io/api to 2.6.0 or later.

Other vulnerabilities in code.vikunja.io/api