CVE-2026-33676 in vikunja
Summary
by MITRE • 03/24/2026
Vikunja is an open-source self-hosted task management platform. Prior to version 2.2.1, when the Vikunja API returns tasks, it populates the `related_tasks` field with full task objects for all related tasks without checking whether the requesting user has read permission on those tasks' projects. An authenticated user who can read a task that has cross-project relations will receive full details (title, description, due dates, priority, percent completion, project ID, etc.) of tasks in projects they have no access to. Version 2.2.1 patches the issue.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 03/28/2026
This vulnerability in Vikunja represents a critical access control flaw that undermines the application's security model and data isolation principles. The issue manifests when the API service returns task objects that contain a `related_tasks` field populated with complete task details from other projects. This behavior occurs regardless of whether the authenticated user possesses read permissions for the projects containing those related tasks. The vulnerability essentially allows privilege escalation through information disclosure, where users can access sensitive data from projects they should not be able to view. This type of flaw directly violates the principle of least privilege and can be categorized under CWE-284 Access Control Bypass, specifically related to insufficient authorization checks during data retrieval operations.
The technical implementation of this vulnerability stems from improper authorization validation within the API response generation logic. When a user requests a task that has cross-project relationships, the system fails to perform access control checks on the related tasks before including them in the response payload. This oversight creates a scenario where the API service indiscriminately exposes full task objects including metadata such as titles, descriptions, due dates, priorities, completion percentages, and project identifiers. The flaw exists in the data serialization layer where the system assumes that because a user can access one task, they automatically have access to all related tasks regardless of project boundaries. This represents a classic case of inadequate input validation and access control enforcement at the application API layer, which can be mapped to ATT&CK technique T1068, which involves exploiting local system permissions to gain access to restricted resources.
The operational impact of this vulnerability extends beyond simple information disclosure, potentially enabling more sophisticated attacks and data exploitation. An authenticated user could leverage this flaw to discover the existence of projects they don't have access to, understand the structure and content of those projects, and potentially identify sensitive information about organizational workflows, timelines, and priorities. This information could be particularly valuable in targeted attacks or social engineering operations where attackers seek to understand the operational context of organizations. The vulnerability affects all users with read access to any task that has cross-project relationships, meaning that even users with minimal permissions could potentially access extensive information from projects they shouldn't be able to view. This creates a significant risk for organizations that rely on project isolation for security or business reasons.
The fix implemented in version 2.2.1 addresses this issue by introducing proper access control checks before populating the `related_tasks` field. The patch ensures that the system validates whether the requesting user has appropriate read permissions for each related task's project before including that task's full details in the response. This remediation aligns with security best practices and industry standards for access control implementation, specifically addressing the need for proper authorization checks at all data access points. Organizations should prioritize updating to version 2.2.1 or later to mitigate this vulnerability, as the fix directly addresses the root cause of the unauthorized data exposure. Additionally, system administrators should consider implementing monitoring for unusual API access patterns that might indicate exploitation attempts, as the vulnerability could potentially be leveraged for reconnaissance purposes before more targeted attacks are initiated.