CVE-2026-55065: Vikunja Privilege Escalation Vulnerability

CVE-2026-55065 Overview

Vikunja is an open-source self-hosted task management platform. CVE-2026-55065 is a broken access control vulnerability [CWE-285] affecting versions from 0.24.6 up to 2.4.0. The flaw resides in the DELETE /api/v1/projects/:project/views/:view endpoint, which authorizes the request against an attacker-controlled project identifier while operating on a view identifier belonging to a different project. An authenticated user can destroy Kanban task_buckets and task_positions assignments across tenant boundaries. The issue is fixed in version 2.4.0.

Critical Impact
Authenticated attackers can destroy Kanban bucket assignments and task ordering data belonging to projects they do not own, causing cross-tenant integrity and availability loss.

Affected Products

Vikunja versions 0.24.6 through versions prior to 2.4.0
pkg/models/project_view_permissions.go (ProjectView.CanDelete)
pkg/models/project_view.go (ProjectView.Delete)

Discovery Timeline

2026-08-28 - CVE-2026-55065 published to NVD
2026-09-01 - Last updated in NVD database

Technical Details for CVE-2026-55065

Vulnerability Analysis

The vulnerability stems from mismatched authorization scoping in Vikunja's project view deletion path. ProjectView.CanDelete in pkg/models/project_view_permissions.go checks admin permissions on the project identifier supplied in the URL path but never verifies that the target view actually belongs to that project. An authenticated user with admin rights on any project of their own can pass their own :project identifier alongside a :view identifier owned by a victim project.

ProjectView.Delete in pkg/models/project_view.go executes a scoped project_views delete that legitimately affects zero rows because the view does not belong to the attacker's project. Execution continues past this no-op. The subsequent cleanup queries delete rows from task_buckets and task_positions filtered only by project_view_id. This destroys the victim project's Kanban bucket assignments and task ordering while leaving the view record and tasks themselves intact, producing a silent integrity failure.

Root Cause

The root cause is an authorization decision made against user-controlled input that is not cross-validated against the operated-on resource. The permission check trusts the path project ID rather than the view's actual owning project.

Attack Vector

Exploitation requires a network-reachable Vikunja instance and any authenticated account with admin rights on at least one project. The attacker enumerates or guesses a target view_id and issues DELETE /api/v1/projects/{attacker_project_id}/views/{victim_view_id}.

// Patched authorization check in pkg/models/project_view_permissions.go
//	return sf.CanDelete(s, a)
//	}

	if _, err := GetProjectViewByIDAndProject(s, pv.ID, pv.ProjectID); err != nil {
		return false, err
	}

	pp := pv.getProject()
	return pp.IsAdmin(s, a)
}

Source: GitHub commit 6895a7765ef1667be4b79df29549d33b9e1ca9ca. The patch introduces GetProjectViewByIDAndProject, which fails the authorization check when the view does not belong to the path project.

Detection Methods for CVE-2026-55065

Indicators of Compromise

Users reporting missing Kanban bucket assignments or reset task ordering while tasks and views themselves remain intact.
DELETE /api/v1/projects/:project/views/:view requests where the :view identifier does not belong to :project in application logs.
Unexpected bulk deletions from task_buckets and task_positions tables without corresponding project_views deletions.

Detection Strategies

Review Vikunja HTTP access logs for DELETE requests to /api/v1/projects/*/views/* and correlate the path project ID with the view's true parent project in the database.
Enable database audit logging on task_buckets and task_positions and alert on delete operations that are not paired with a matching project_views delete in the same transaction.
Compare the population of task_buckets and task_positions against historical baselines to identify sudden drops.

Monitoring Recommendations

Forward Vikunja application and reverse-proxy logs to a centralized logging platform for cross-project deletion pattern analysis.
Alert on any authenticated user issuing view-deletion requests across multiple project IDs within a short window.
Track authorization failures returned by the patched GetProjectViewByIDAndProject check after upgrade to detect probing.

How to Mitigate CVE-2026-55065

Immediate Actions Required

Upgrade Vikunja to version 2.4.0 or later, which contains the fix.
Audit task_buckets and task_positions for unexpected deletions and restore from backup where necessary.
Rotate API tokens for any accounts that exhibited anomalous view-deletion activity.

Patch Information

The fix is delivered in Vikunja v2.4.0. See the GitHub Security Advisory GHSA-gg93-x632-9ccv, Pull Request #3239, and Release v2.4.0. The patch adds a GetProjectViewByIDAndProject lookup in ProjectView.CanDelete and ProjectView.CanUpdate that rejects requests where the view does not belong to the path project.

Workarounds

Restrict access to the Vikunja API to trusted users while the upgrade is scheduled.
Place the DELETE /api/v1/projects/:project/views/:view endpoint behind a reverse-proxy rule that validates the requesting user's ownership of the view identifier.
Take regular database backups of task_buckets and task_positions to enable rapid recovery from destructive cross-tenant calls.

bash

# Verify the running Vikunja version and upgrade
docker inspect vikunja --format '{{.Config.Image}}'
docker pull vikunja/vikunja:2.4.0
docker compose up -d vikunja