CVE-2026-55065

Vikunja versions 0.24.6 until 2.4.0 fail to verify that the view identifier supplied to DELETE /api/v1/projects/:project/views/:view actually belongs to the project named in the request path, an authorization bypass (CWE-285/CWE-639). An authenticated user can therefore call the endpoint with their own (attacker-controlled) project identifier and a view ID from another project or tenant, and the permission check in ProjectView.CanDelete passes. Because the follow-up deletes of task_buckets and task_positions key only on project_view_id, the attacker wipes another project's Kanban bucket assignments and task ordering even though the scoped delete on the victim's project_views row affects no rows; the victim's view and tasks themselves remain intact. The impact is loss of integrity and availability of Kanban board data (high/high per CVSS) with no confidentiality impact, and it is most relevant to multi-user or multi-team Vikunja instances running affected versions. There is no known public proof-of-concept, the flaw is not in CISA KEV, and EPSS puts 30-day exploitation probability at only 0.3%, so no exploitation is currently known.

What to do: Upgrade Vikunja to version 2.4.0 or later, which fixes the cross-project view authorization flaw. Until patched, restrict DELETE access to the /api/v1/projects/.../views/... endpoints to trusted administrators, and review Kanban views (buckets and task ordering) for unexplained changes, since cross-project deletions leave the victim view and tasks seemingly intact. Audit API access logs for DELETE calls to project-view endpoints made with view IDs that do not match the path project.