Attack Chain

1. Attacker registers a local account on the target Vikunja instance (no special privileges required).
2. Attacker creates a new project via PUT /api/v1/projects, granting themselves Admin access to the new project ID (P_A).
3. Attacker identifies a victim Kanban view ID (V) by enumerating projects or observing API traffic.
4. Attacker constructs a malicious DELETE request: DELETE /api/v1/projects/P_A/views/V.
5. The application's CanDelete method validates the user is an admin of P_A and permits the request.
6. The ProjectView.Delete method executes the first scoped SQL statement, which fails silently because V does not belong to P_A.
7. The function proceeds to execute subsequent unscoped SQL DELETE statements on the task_buckets and task_positions tables using V.
8. All Kanban organization data for the victim view V is permanently deleted from the database.

Impact

Successful exploitation results in the permanent loss of all task-to-bucket mappings and custom task ordering for the targeted Kanban view. This causes significant operational disruption for teams relying on Kanban boards, requiring manual reconfiguration or restoration from database backups. The vulnerability is highly accessible as it requires only standard user registration.

Recommendation

1. Upgrade Vikunja immediately to the version containing the security patch that enforces project-view relationship validation within the ProjectView.Delete model method.
2. Implement strict input validation to verify that view_id maps to the project_id provided in the API request before any database modification occurs.
3. Ensure database backups are performed regularly and tested for restoration to mitigate the impact of data destruction vulnerabilities.
4. Review audit logs for DELETE operations on the project_views endpoint that target views not associated with the authenticated user's project ownership.