Vikunja is an open-source, self-hosted task management platform that allows users to manage projects and share links associated with those projects. The vulnerability identified as CVE-2026-33700 (CWE-639: Authorization Bypass Through User-Controlled Key) affects versions of Vikunja prior to 2.2.1. Specifically, the DELETE endpoint at /api/v1/projects/:project/shares/:share does not properly verify that the link share being deleted actually belongs to the project specified in the URL path. This improper authorization check allows an attacker who has administrative access to any single project within the Vikunja instance to delete link shares from other projects by supplying their own project ID combined with the target share ID from another project. The vulnerability arises because the server trusts the project ID parameter without cross-checking ownership of the share resource, leading to an authorization bypass. Exploitation requires the attacker to have admin privileges on at least one project, but no further user interaction or authentication bypass is needed. The flaw impacts the integrity of project data by enabling unauthorized deletion of shares, potentially disrupting collaboration and causing data loss. The issue was addressed and fixed in Vikunja version 2.2.1 by adding proper authorization checks to ensure that the share belongs to the project before allowing deletion. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N) indicates network attack vector, low complexity, no user interaction, but requiring high privileges (admin on a project), with a medium severity score of 6.9.

The primary impact of this vulnerability is unauthorized deletion of link shares across projects within a Vikunja instance. This can lead to data integrity issues, loss of shared resources, and disruption of team collaboration workflows. Since the attacker must have admin access to at least one project, the scope is limited to insiders or compromised accounts with elevated privileges. However, in environments where multiple projects are managed by different teams or clients on the same Vikunja instance, this flaw could allow an attacker to interfere with other teams’ data, potentially causing operational disruption and loss of trust. The vulnerability does not allow full project deletion or access to confidential data but undermines the integrity and availability of shared links. Organizations relying on Vikunja for task and project management, especially those with multi-tenant or multi-team deployments, are at risk of internal sabotage or privilege abuse. The lack of known exploits in the wild reduces immediate risk, but the vulnerability’s presence in a network-accessible API endpoint means it could be targeted by malicious insiders or attackers who have gained partial access.

To mitigate this vulnerability, organizations should upgrade all Vikunja instances to version 2.2.1 or later, where the authorization checks have been properly implemented. Until the upgrade is applied, administrators should restrict project admin privileges to trusted users only and monitor for suspicious deletion activity of link shares. Implementing strong access controls and auditing on project admin roles can reduce the risk of exploitation. Additionally, network segmentation and limiting API access to trusted networks or VPNs can reduce exposure. Regularly reviewing logs for anomalous API calls to the DELETE /api/v1/projects/:project/shares/:share endpoint can help detect attempts to exploit this flaw. For organizations running multi-tenant Vikunja instances, consider isolating projects or using separate instances to minimize cross-project privilege abuse. Finally, maintain an up-to-date inventory of Vikunja versions deployed and ensure timely patch management processes are in place.