CVE-2026-33700 in vikunja
Summary
by MITRE • 03/24/2026
Vikunja is an open-source self-hosted task management platform. Prior to version 2.2.1, the `DELETE /api/v1/projects/:project/shares/:share` endpoint does not verify that the link share belongs to the project specified in the URL. An attacker with admin access to any project can delete link shares from other projects by providing their own project ID combined with the target share ID. Version 2.2.1 patches the issue.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 03/30/2026
The vulnerability identified as CVE-2026-33700 represents a critical access control flaw within the Vikunja task management platform that affects versions prior to 2.2.1. This issue resides in the RESTful API endpoint designed for managing project share permissions, specifically the DELETE operation targeting project shares. The vulnerability stems from improper input validation and authorization checks that fail to enforce proper access boundaries between projects, creating a path for privilege escalation through cross-project resource manipulation. The affected endpoint `DELETE /api/v1/projects/:project/shares/:share` lacks adequate verification mechanisms to ensure that the share being deleted actually belongs to the project specified in the URL path, allowing unauthorized access to project resources.
The technical exploitation of this vulnerability occurs through a simple but effective manipulation of API parameters where an attacker with administrative privileges in one project can construct a malicious request by combining their own project ID with a target share ID from another project. This misconfiguration creates a direct path for unauthorized deletion of link shares, effectively bypassing the intended access control mechanisms that should prevent users from manipulating resources they do not own. The flaw demonstrates a classic case of insufficient authorization checks where the system fails to validate ownership relationships between resources, a weakness that directly maps to CWE-285, which addresses improper authorization in software systems. The vulnerability operates at the application layer and requires minimal technical expertise to exploit, making it particularly dangerous in environments where administrative privileges might be compromised.
The operational impact of this vulnerability extends beyond simple data loss, as it fundamentally undermines the security model of the Vikunja platform by allowing unauthorized access to project share configurations. Administrators may lose control over their project permissions, potentially exposing sensitive task data or disrupting collaboration workflows. Attackers could leverage this vulnerability to remove legitimate share links that provide access to important project information, effectively creating a denial of service condition for legitimate users. The vulnerability also represents a potential data integrity risk where malicious actors could systematically remove project shares to disrupt workflows or gain insights into project structures. From a threat modeling perspective, this issue aligns with ATT&CK technique T1078 which covers valid accounts used for persistence, as compromised administrative credentials could be used to exploit this vulnerability and maintain unauthorized access to multiple projects.
Organizations using Vikunja versions prior to 2.2.1 should immediately implement the patch released in version 2.2.1, which addresses the authorization flaw by implementing proper validation of share ownership relationships. The mitigation strategy should include comprehensive monitoring of API access patterns to detect unusual deletion activities, particularly those involving cross-project resource manipulation. System administrators should also conduct thorough access control reviews to ensure that project-level permissions are properly enforced and that no unnecessary administrative privileges exist within the platform. Additional defensive measures include implementing rate limiting on API endpoints, enabling detailed audit logging for all share management operations, and conducting regular security assessments of the platform's API endpoints to identify similar authorization gaps. The vulnerability serves as a reminder of the critical importance of proper input validation and access control implementation in multi-tenant applications where resource boundaries must be strictly enforced to prevent privilege escalation attacks.